我们把大量的文件放在文件系统中，以备以后分析。 我们无法控制我们将要拥有的文件数量，而这一个盒子需要访问所有文件。
为了规避这个严峻的限制，还有哪些其他的方面呢？ 我提到的方法还有其他的好处/缺点吗？
我build议你使用一个networking服务器来处理你所需要的文件系统。 首先想到的是支持zfs的东西（freenas和nexenta，虽然后者的免费版本有一些限制），或者如果你买得起，你可以买netapp之类的东西。
我不熟悉freebsd上可用的UFS，但听说也可以。
我们缺less的信息…
ext4听起来不像你想要的那样。 所以不要用它…
XFS应该很好地处理你的情况。 它在Linux内核中，但部署很大程度上取决于您的磁盘灵活性。 还有一些XFS可调参数将帮助您的负载…开箱，它不会运行得很好。 你会想要正确的文件系统创build和挂载选项 。 剩下的就取决于你的发行版，不pipe你使用的是控制器还是你的特定工作负载。
我想你回答了你自己的问题，XFS选项似乎是最好的（我猜你甚至可以获得性能提升）。 更复杂的部分应该是如何将EXT3 / 4转换成XFS？
如果你的存储不是唯一的物理RAID VD（而且你没有在BlockDevice上直接创buildfs – mkfs.ext4 / dev / sdb），那么我可能会build议你将fs树分成更小的块并相应地挂载它们，将软件configuration为同时写入两个位置，并尽可能分割写入。 防爆。
如果不能从应用程序中分割写入，则可以创build一个cron，每n分钟将文件从ext4分区移动到新的XFS中
其他选项：
根据需要创build文件系统。 使用LVM分区，而不是直接将文件系统附加到MBR。 您可以在树中的任何位置安装FS，这样您可以随时随地添加新的文件系统。 另外，如果需要，LVM可以跨越多个磁盘的部分，这意味着物理介质边界的意义不大。
环回FSes不是一个可怕的想法，但真的为什么不使用LVM呢？ 所有的优点，没有任何的缺点。
如果你只是归档文件（即不是随机访问），然后将它们直接保存到一个.tar.gz文件不是一个坏主意。 我也看到了一些系统，在系统结构正在build立的时候，文件被临时“暂存”到SSD中，然后在旋转驱动器上被转储为tar.gz以进行长期存储。
XFS并不是一个糟糕的select，尽pipe它也有其自身的困难。 例如，这不完全像不干净的closures。 不是说你会期望数据丢失，但有时需要更多的实际操作。
所有这些，自动推送文件到.tar.gz档案是我的最爱。 它节省了你的空间和inode，而且简单整洁。 大量的小文件使得文件系统的性能低于预期。