我的工作与存储相关，并且也喜欢文件系统。但是最近，与朋友一起讨论有关了Linux文件系统和一般文件系统的问题时，我们得出一个结论：我们遇到了文件系统扩展问题。
文件系统规模大小的瓶颈
很明显，文件系统社区作为一个团体还没有引起我足够的关注，目前他们已经在某些领域取得了进展，但Linux文件系统单个命名空间500TB的目标似乎仍然遥遥无期。
▲文件系统规模大小
当我们谈到上述文件系统的优点和缺点时，最大的问题在于，文件系统的大小限制和如今存储设备的容量相比，实在是小得让人难以置信。
使用容量为3TB的硬盘，ext3/4文件系统最大可支持5块硬盘，我们认为很少有人会买5块容量为3TB的硬盘放进PC，XFS最大可以支持33块3TB硬盘，即使如此，在我们看来还是太小了。显然，文件系统支持的大小没有随硬盘容量，或大数据需求增长而扩容。我有一个家用NAS设备，带有6块硬盘，幸好我没有买带有8块硬盘的NAS，因为XFS不支持我的NAS厂商，我想超过ext3文件系统的大小限制，必须创建多个文件系统。
文件系统模型的两个问题
可能有些人会提出质疑，让我提前预演你们的问题并给予解答。第一个可能的问题是“为什么你们需要这么臭的支持，下载下去自己调试不就成了吗?大家都懂的”，这可能是真的，但事实是，它与我们无关 — 它与目前业务的市场现实有关(记住，我们都是Linux的支持者，每周都会写有关Linux和存储的系列文章)。
第二个可能的应答是“你们很愚蠢，不应该要那么大的文件系统”，你告诉我们不想要这些大文件系统的原因是，因为它们不能扩展，但我们需要它们，并且我们的客户也需要它们，当支持8块硬盘的NAS必须分解成多个文件系统时，我想我们的文件系统发展和支持模式已经被打破了。
我们做了一些检查，最后认为有两个问题：
1、在当前的文件系统模型中，列举文件系统存储的大量文件时存在元数据扩展问题，虽然XFS可支持到100TB，但我们看到，在存储大量文件时，性能下降得非常利害，特别是当元数据变得支离破碎时。
2、这些文件系统增长已经接近它们的极限，性能表现似乎没有和容量呈线性增长，反而随碎片增多下降了。
我们决定研究一下第一个问题，因为没有可扩展元数据，我们认为，持续的大数据块性能并不重要，我一直是fsck的巨大支持者，部分厂商过去曾表示，所有你必须做的是检查日志，你永远都不需要验证文件系统。
但这完全没用，我们都遇到过无数的硬件问题，但我们从来没有见过一个运行的文件系统可以从一个RAID恢复。这是POSIX文件系统的本性，事实上，只有元数据有日志记录，鉴于性能影响，数据没有日志记录。我们推断，Linux限制文件系统大小的一个主要原因是，在发生硬件事件后，它运行一次fsck所花的时间长短，在系统崩溃后，它要运行fsck检查元数据(如超级块，inode，范围和目录)，特别是存储发生硬件事件后做这个检查是极其重要的。
海量存储测试很有必要
我们认为，如果有人真的使用50TB或100TB存储，在文件系统中每个目录放入多个文件，总量达5000万-1亿个文件(甚至10个文件)，测试ext4和xfs文件系统，他一定是个了不起的人，我们认为这个想法非常棒，但截至目前还没有人做过这个测试。到处宣传，希望有人实现这个疯狂的想法。
我们都认为大文件系统的问题在于元数据扫描速度，假设你的文件系统中有1亿个文件，文件系统的扫描速度是每秒5000个inode，如果遇到系统崩溃，fsck需要花20000秒或大约5.5小时，如果你是一家企业，你需要花一大半工作日等待fsck结束，这是不可接受的。现在，鉴于网络速度和系统处理能力的提升，包含1亿文件的文件系统可能不会花那么多时间，单个文件服务器可以支持100用户，每用户100万文件，这个数字够大，但还不够疯狂。另一个问题是，我们不知道包含大量文件的大文件系统的扫描速度，如果这个数字不是5000而是2000会怎么样?使用企业级3.5英寸硬盘，每块硬盘的IOPS介于75-150，20块硬件将可以实现至少1500 IOPS，问题是对两个文件系统使用fsck可以实现的硬件带宽百分比有多大?这就是我们要调查的。
最后一个意见：我们听起来可能很悲观，但我们知道Red Hat开发人员，如Dave Chinner和Eric Sandeen，一直在努力改善XFS的元数据性能，这些测试的目标之一是，看看他们所做的努力是否改善了fsck性能，是否值得企业生产系统采纳。
原文出处：http://www.enterprisestorageforum.com/storage-hardware/the-state-of-file-systems-technology-problem-statement.html
原文名：The State of File Systems Technology, Problem Statement
作者：Henry Newman
