我正在开发一个需要在一个ext2文件系统的Linux发行版上运行的程序。 这个程序将写入可能会变得非常大的文件。 我注意到，ext2的最大文件大小为16GB到64GB。 然而，维基百科页面上的一件事情让我感到有些害怕，如下所示：
还有许多用户空间程序无法处理大于2 GB的文件。
…当谈到ext2的限制时。 这是否意味着我应该小心让一个文件增长大于2 GB？
你会发现一些程序使用“fseek”在文件中移动。
int fseek ( FILE * stream, long int offset, int origin ); 如果他们做的是相对于文件开始的东西（SEEK_SET作为原始参数），那么他们只有一个有符号的32位整数作为偏移量参数，所以他们只能得到2 gig的文件。
对于不使用fseek / ftell的程序（例如，一个只读取整个文件的程序），对于只使用fseek从当前位置来回跳转的程序（带偏移量的SEEK_CUR <2G），没有问题，无论文件有多大，一切都可以正常工作。 它只是随机访问将有问题的文件数据的程序。
请注意，某些环境具有“fseek64”和“ftell64”的function，给调用者一个64位的有符号整数，从而访问他们想要的任何东西。
我从来没有遇到过问题，而且我的系统日志通常比我的某些外部IP服务器上的2台服务器大（日志每周旋转，而不是大小）。 我也运行一些大规模的饲料，产生3-6演出大小的文件，我也没有与这些问题。
我会说这完全取决于你需要的用户程序：如果有交易断路器，你可能需要重新评估。
文件大小限制取决于文件系统的块大小。 单个文件的限制是16GB，如果你有一个1K的块大小，256GB的2K和4TB的4K。 你可以使用
mojo-jojo david% sudo tune2fs -l /dev/sda1 | grep "Block size" Block size: 4096
这是一个ext3分区，但它们会有相同的限制。 如果你有一个1K块大小的分区，我会非常惊讶，因此你不必担心文件系统。
话虽如此，有些程序确实没有大文件支持（大于2GB），但我很久没有见过。 我看到的最后一个是commons-java的jsvc，当日志文件大于2GB时，jsvc就崩溃了。 几乎所有在过去的六年中写的东西都会起作用，除非有人不顾一切地做些奇怪的事情。
2 GB的限制起源于旧系统的ssize_t / size_t / off_t的32位大小。 这是POSIX规范的端口，与ext2没有特别的关系。
正如在上面的评论中提到的那样，您可以使用标志“_FILE_OFFSET_BITS = 64”来编译您的应用程序，以使这些types的大小为64位。
这里是一篇关于Linux中大文件支持状态的文章 。