我计划升级一个免费的软件镜像服务器，我会很高兴build立新的主磁盘的build议。
我目前的用法：
我可能会得到44TB的磁盘，我将分布在三个硬件RAID-5arrays总共34TB（加上备用）。
我以为我会把arrays变成LVM2 PVs，并build立一个34TB的VG，我会以某种方式拆分，为每个镜子做一个LV。 然后我会为每个发行版分配一个extN或XFS卷。
一个问题是，我不能真正预测任何镜子的增长。 我可能不得不在每个LV中创造大量的开销，或者经常增长LV。 大镜面收缩不是真正的问题; 他们越来越大。 如果多次调整LV大小，会导致碎片增加，从而导致性能下降吗？
我可能想要优化一些文件系统的特定工作负载，如小文本文件或CD映像，所以这是对使用单个FS的罢工。 多FS方法可以让我更容易地跟踪发行版的磁盘使用模式。 保持one-big-FS的最后一个可能的缺点是操作系统在树上search。 这有多less关注？
我会有24或48GB的内存，我计划每月提供30-50TB，有几个大文件（安装程序，光盘镜像）碰到caching，许多2-20MB文件丢失。
首先，远离RAID。 这是不值得的。 14TBarrays重build将需要数天时间。 你不想让你的磁盘搅拌好几天，那么当更换磁盘时，最好丢掉镜像的一部分并重新获取数据。
LVM是很好的，当然可以用于你的小镜子，但是我不确定这对于主存储有多大的帮助。 LVM的问题在于任何事情的失败都会影响整个PV，所以你不需要太多的PV。
您可能会遇到IO负载平衡问题，这会迫使您在磁盘之间平衡IO（例如，您的Ubuntu镜像可能会很难被击中）。 因此，我build议您使用某种types的图层，以便在磁盘之间重新分配IO负载。
处理大型且不断增长的镜像存储时，一个典型的解决scheme是创build一个抽象层，用于跟踪文件位于磁盘上的位置（通常使用数据库），然后将这些文件分散到多个物理磁盘上，而不会冗余。 这是内置于许多NAS解决scheme中的。
你可以在这里find更多的信息。
考虑到arrays的大小以及即将扩展的事实，我build议使用RAID-6而不是RAID-5 +arrays。 在我的硬件重build20TBarrays大约需要2-3周，所以如果你使用RAID-5和驱动器失败，你将在重build过程中长时间的风险。 logging事实也certificate，重build过程中会发生许多故障，这对于RAID-5arrays是致命的。
虽然我不能评论分区。 我个人避免有太多的分区，我宁愿有一个大的分区（可能是两个:-)，有时为了可pipe理性和便利性而取消潜在的性能增益。
我最近还在为一个系统分区练习一个小型SSD，主要是因为SSD硬盘的可靠性。 尽pipe如此，这种做法仍然被认为是有问题的。