只是好奇 Linux 上一些流行的文件系统提供的最大文件大小限制，我看到有些达到了 TB 规模。
我的问题是，如果文件指针是 32 位宽，就像我们今天遇到的大多数 Linux 一样，这是否意味着我们可以寻址的最大距离是 2^32-1 字节？那么如何存储大于 4GB 的文件呢？
另外，即使我们可以存储这样一个文件，我们如何定位到超出 2^32 范围的位置呢？
【问题讨论】：
标签： linux file filesystems size 32-bit
要使用大于 4 GB 的文件，您需要 Linux 上的“大文件支持”(LFS)。 LFS 引入的更改之一是文件偏移量是 64 位数字。这与 Linux 本身是在 32 位还是 64 位模式下运行（例如 x86 与 x86-64）无关。参见例如http://www.suse.de/~aj/linux_lfs.html
LFS 主要是在 glibc 2.2 和内核 2.4.0 中引入的（大约在 2000-2001 年），所以任何最近的 Linux 发行版都会有它。
要在 Linux 上使用它，您可以使用特殊函数（例如 lseek64 而不是 lseek），或者设置 #define _FILE_OFFSET_BITS 64，那么常规函数将使用 64 位偏移量。
【讨论】：
至少在 Linux 中，编写程序以显式处理更大的文件是很简单的（即，不只是使用 kohlehydrat 建议的流式方法）。
例如，请参阅this page。诀窍通常归结为在包含一些系统标头之前拥有一个魔术#define，这会“打开”“大文件支持”。这通常会将文件偏移类型的大小翻倍至 64 位，这是相当多的。
【讨论】：
没有任何关系。 C stdio 中的FILE * 指针是一个不透明的句柄，与磁盘文件的大小无关，它指向的内存也可能比指针本身大得多。函数fseek()，用于重新定位我们读取和写入的位置，已经使用long，而fgetpos() 和fsetpos() 使用不透明的fpos_t。
使处理大文件变得困难的是off_t 在各种系统调用中用作偏移量。幸运的是，人们意识到这将是一个问题，并提出了“大文件支持”（LFS），这是一个修改后的 ABI，对于偏移类型off_t 具有更宽的宽度。 （通常这是通过引入一个新的 API 并#defineing 旧名称来调用这个新的 API 来完成的。）
【讨论】：
您可以使用lseek64 来处理大文件。 Ext4 可以处理 16 个 TiB 文件。
【讨论】：
只要反复调用read(int fd, void *buf, size_t count);
（因此不需要指向文件的“指针”。）
从文件系统设计的角度来看，您基本上拥有一个索引树（索引节点），它指向构成实际文件的多个数据（块）。使用此模型，理论上您可以拥有无限大小的文件。
【讨论】：
UNIX 对文件大小的实际物理限制取决于 32 位文件指针可以索引的字节数，大约为 2.4 GB。
考虑在第一个文件长度达到 0x7fffffff 字节之前关闭第一个文件，然后再打开一个新文件。
ext2 文件系统的一些限制的原因是数据的文件格式和操作系统的内核。大多数这些因素将在构建文件系统时确定一次。它们取决于块大小以及块数和 inode 数的比率。在 Linux 中，块大小受架构 page size 的限制。
还有一些用户空间程序无法处理files larger than 2 GB。
由于i_block (an array of EXT2_N_BLOCKS) 和i_blocks( 32-bits integer value ) 代表文件中b 字节“块”的数量，最大文件大小限制为min( (b/4)3+(b/4)2+b/4+12, 232*b )。
【讨论】：