一直困扰着我的是存储最佳实践。 文件系统吹嘘他们如何可以是PB或EB的大小。 然而，我不知道许多系统pipe理员愿意让一个卷的增长超过几个terrabytes。 我知道这背后的主要原因是，如果驱动器出现故障，重buildarrays需要多长时间。 单个LUN中的驱动器越多，需要的时间越长，重build过程中丢失另一个驱动器的风险也越大。
那么有使用的原因。 pipe理员将根据他们认为需要分配给项目的空间划分出一个LUN。 对我来说，LUN是一个大arrays并使用配额似乎更为实际。 我知道这不能满足每个需求（iSCSI），但我看到很多NAS系统（NFS）以这种方式pipe理。 我也明白，可以根据需要轻松地扩大/缩小基础卷，但是使用配额而不是操作卷并将可能的数据丢失带入等式不会更“冒险”吗？
我可能还有一些其他的原因，所以请赐教。 难道我们不希望文件系统如此之大吗？ 我们是否正在等待硬件更快地缩短重build时间？
主轴分离不是一个大的体积的好理由。 如果您正在运行Exchange，SQL Server和其他随机事物（ESXi来宾），那么您肯定会想要分离主轴。 交换数据和长整数应该在彼此独立的主轴上以及SQL数据库和日志上。
重build驱动器不取决于文件系统，而取决于驱动器本身。 如果你使用2TB硬盘，那么你将需要很多时间来重build。
重build是raid 5的一个问题。对于这个现在可能控制器支持raid 6或更好，你可以做一个突袭10（如果你想要最好的performance）。 导出一个LUN是一个SAN的工作，导出一个文件系统是NAS的工作。
两者都有其优点和缺点（谷歌search，有大量的文件）。 制作大量独立的LUN（或文件系统）具有快照备份的优势。
就我个人而言，我不会在iSCSI或NFS上运行真正的企业stream量（Oracle，MSSQL，Production ESX） – 我知道并信任FC，无论是在一般性能还是在故障情况下。 哦，当然，这意味着我不能只创build大量的LUN和细分，它确实会带来相当多的复杂性/工作量，但是我们的系统可用性和最终用户体验数据比我们所希望的更好，更一致。
至于你的实际答案 – 那么你的post看起来非常适合NetApp / filer，因此我最后一段 – 但是你自己已经列出了原因。 磁盘接口已经大大落后于磁盘容量 – 这意味着重build时间可能是荒谬的，特别是如果你想在重build到现有的stream量期间看到体面的performance。 磁盘一直在死，在重build过程中影响多平台性能的想法只是简单地让pipe理员的生活变得简单，实际上却是一个短暂的方法。 纯粹从平台安全angular度来看，您可能想要对系统进行分区，而“大LUN”方法可能无法在这种情况下运行（当然，基于硬件）。
最终，企业级SAN本质上是业务或关键任务，要求可用性和一致性，而不是成本，简化pipe理甚至是最终的性能。