The answer is found in the Linux source, specifically, /usr/src/linux/mm/shmem.c
, starting around line 70 on my system (Gentoo 2.6.31-ish):
/*
* The maximum size of a shmem/tmpfs file is limited by the maximum size of
* its triple-indirect swap vector - see illustration at shmem_swp_entry().
*
* With 4kB page size, maximum file size is just over 2TB on a 32-bit kernel,
* but one eighth of that on a 64-bit kernel. With 8kB page size, maximum
* file size is just over 4TB on a 64-bit kernel, but 16TB on a 32-bit kernel,
* MAX_LFS_FILESIZE being then more restrictive than swap vector layout.
One-eighth of 2 TB is exactly 256 GB. Larger sizes are possible with a 32-bit kernel, as you discovered with your 32-bit FC6 test system.
It appears that changing the page size may be related to enabling HugeTLB filesystem support in the kernel. However, I don't know enough about the guts of the kernel to say how or why, or what steps you need to take to take advantage of it, or what other implications it might have. To enable it, run make menuconfig
, navigate to File systems, and then Pseudo filesystems. The option in question is HugeTLB file system support. The online help for it says:
CONFIG_HUGETLBFS:
hugetlbfs is a filesystem backing for HugeTLB pages, based on
ramfs. For architectures that support it, say Y here and read
<file:Documentation/vm/hugetlbpage.txt> for details.
If unsure, say N.
It might be worth running this by StackOverflow, too. I hope this helps.
Best Answer
I've been running LUKS encrypted filesystems for over a decade, with ext2/3/4, XFS, ZFS and maybe some other filesystems I've forgotten about. While I don't have any benchmarks handy, I do have a few notes to share:
The only real performance issue you have with LUKS is the encryption and decryption itself. This introduces some latency to the process and has the potential to make disk I/O CPU-bound. On older systems without hardware AES acceleration on-chip, this was a significant issue. Today, as long as you have AES-NI in your processor and a kernel from this decade, it's almost unnoticeable for moderate workloads. Better still if you have a recent (3.x+?) kernel which can do crypto in multiple kernel threads.