RHEL5：无法在 tmpfs 中创建大于 256GB 的稀疏文件

Question

/var/log/lastlog在您登录时写入。此文件的大小基于系统中最大的 UID。最大 UID 越大，这个文件就越大。值得庆幸的是，它是一个稀疏文件，因此磁盘上的大小远小于大小ls报告（ls -s报告磁盘上的大小）。

在我们的系统上，我们针对 Active Directory 服务器进行身份验证，分配给用户的 UID 最终非常非常大。例如，第一个 AD 用户的 UID 为 900,000,000，第二个用户的 UID 为 900,000,001，等等。

这很奇怪，但应该没问题。但是，它会导致/var/log/lastloghuuuuuge - 一旦 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 系统上这是不行的。

Answer 1

答案可以在 Linux 源代码中找到，具体来说，/usr/src/linux/mm/shmem.c从我的系统（Gentoo 2.6.31-ish）的第 70 行开始：

/*
 * 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 位内核可以使用更大的尺寸。

似乎更改页面大小可能与在内核中启用HugeTLB 文件系统支持有关。但是，我对内核的本质知之甚少，无法说明如何或为什么，或者您需要采取哪些步骤来利用它，或者它可能具有什么其他影响。要启用它，请运行make menuconfig，导航到File systems，然后导航到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 运行它。我希望这有帮助。