在我们的系统上,我们正在针对Active Directory服务器进行身份验证,并且UID用户被分配到最终真的非常大.比方说,第一个AD用户的UID为900,000,第二个用户为900,001,等等.
这很奇怪,但应该没问题.然而,它会导致/ var / log / lastlog成为huuuuuge – 一旦AD用户登录lastlog,就会显示为280GB.幸运的是,它的实际尺寸仍然很小.
当/ var / log / lastlog存储在ext3文件系统的硬盘驱动器上时,这很好.但是,如果lastlog存储在tmpfs文件系统中,它就会中断.然后看来tmpfs上任何文件的最大文件大小是256GB,因此sessreg程序错误地尝试写入lastlog.
256GB限制来自何处,我该如何增加它？
作为创建大型稀疏文件的简单测试,我一直在做：
dd if=/dev/zero of=sparse-file bs=1 count=1 seek=300GB
我试过谷歌搜索“tmpfs最大文件大小”,“256GB文件系统限制”,“linux最大文件大小”,这样的事情.我找不到多少.我唯一能提到的256GB是带有2KB块的ext3文件系统,限制为256GB文件.但我们的硬盘驱动器是用4K块格式化的,所以似乎不是这样 – 更不用说这是在硬盘驱动器上安装的tmpfs中发生的,所以ext3分区不应该是一个因素.
这一切都发生在64位Red Hat Enterprise Linux 5.4系统上.有趣的是,在我的个人开发机器上,这是一个32位的Fedora Core 6机箱,我可以在tmpfs文件系统中创建300GB文件没问题.在RHEL5.4系统上它是不行的.
@R_502_323@
/* * 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.
2 TB的八分之一正好是256 GB.正如您在32位FC6测试系统中发现的那样,使用32位内核可以实现更大的尺寸.
似乎将页面大小may be related更改为在内核中启用HugeTLB filesystem support.但是,我不太了解内核的内容,不知道如何或为什么,或者您需要采取哪些步骤来利用它,或者它可能具有的其他含义.要启用它,请运行make menuconfig,导航到文件系统,然后运行Pseudo filesystems.有问题的选项是HugeTLB文件系统支持.它的在线帮助说：
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.
StackOverflow也可能值得运行它.我希望这有帮助.
