我们的旧 32TB RAID6（净容量：26TB）系统已经老化并需要升级，因此我们目前正在考虑建立一个新的 100TB 系统。
该存储主要用于我们用户的主目录、共享项目数据（使用媒体，因此项目最多可以达到 1TB）以及
旧存储通过 iSCSI 连接到 Debian 主机；文件服务器通过NFS（对于 un*x 主机）和SMB（对于 W32）导出数据。出于实际原因，我们希望保留这一点。
过去，我们发现项目数据会在意想不到的末端增长，因此我们使用一个平面存储池，其中所有项目（和主目录）都位于同一个文件系统中（而不是预先为给定项目分配一定数量的存储容量，然后在达到限制时重新分配）。虽然这是一个简单而灵活的解决方案，但我记得即使使用旧设置也会遇到一些限制。旧 RAID 系统上最大的分区是 20TB，因为它xfs不允许我创建更大的文件系统（那时；更不用说ext4；我并没有真正考虑过zfs——btrfs现在仍然没有）。
由于我没有特别关注存储方面的最新进展，所以我有点搞不清楚目前创建这种中型存储的最佳实践是什么：JBOD、LVM、RAID、分布式文件系统；堆叠在哪个上？一些博客建议RAID6 已经过时了，但还有什么其他选择呢？
我的要求是：
- 净容量~100TB
- “平面”文件系统视图
- 冗余（可承受多个并发磁盘故障）
- 白盒系统
- 在 Debian (Debian/stretch) 上运行
互联网SCSI
可扩展：理想情况下，这样的系统应该允许增长（例如，我开始有 70TB，后来随时购买磁盘，直到达到满容量，并且堆栈也会随之扩展：文件系统会增长，并且数据仍然以冗余方式存储，希望不需要大量单独的 RAID6 系统）。
答案1
使用 ZFS。如果您想要 Debian，ZoL 就是您的最佳选择。
答案2
RAID 6 远未过时 - 但 RAID 5 已经过时了。我不喜欢单控制器存储，您知道单点故障，但如果您对此感到满意，那么请务必继续使用与现在类似的存储。当然，您现在可能会选择某种基于闪存的前端 - 通过缓存或分层 - 这取决于您想要在哪里进行实际 RAID - 我喜欢硬件控制器，您可能不喜欢。无论哪种方式，如果您可以达到 90% 的 IO 来自/到闪存（SSD/NVME 等）的程度，那么您的用户确实会非常高兴。
答案3
老实说，你描述的似乎与 Linus 的工作量类似，可能文件大小较小，但基于 Linux 的操作系统和大尺寸要求相同。看看他的storeanator 评论并给出45drives 的朋友们看一下吧。