虽然可能缺，但感觉症状不像是因为缺 D 。

没准是这个时节普遍困倦，我和我身边最近也有这个感觉。

每块硬盘功率在 10W 左右，家用 CPU 哪怕是 i7 只要不超频待机功耗也只有 40-60W ，工控和低功耗平台更低，所以通常情况下功耗大头是硬盘。

我之前的方案就是迎广 MS04+J4105 ，迎广这个机箱设计非常好，留半高 PCIe 背板甚至可以搞个 HBA 卡做盘位扩展，不过价格不便宜。J 系列 CPU 基本也就只能跑存储了，跑应用会很卡。

看上面有回复说 TDP ，这个是散热参数，不是功耗，一般散热器都会标适用于多少 TDP ，功耗得看实际测评。

查了查，Linux 代码里写死的是文件名最长 255 字符，路径长度最长 4096 字符，如果要改可能需要自己改内核源码并重新编译。

写个脚本批量改下名字呗，感觉要想舒心地用各种基于 Linux 的 NAS 系统，这个是早晚要做的事情。

@standin000 想要避免断电故障加个 ups 就行了。
断电除了硬件伤害可能还有数据伤害，比如某些阵列在断电后会导致硬盘数据不一致。又或者是内存缓存数据没来得及写入硬盘断电导致丢失。

USB 也是有额定带宽，带宽够的话应该也是可以的，只不过使用 USB 的方案实际上是 USB 外接一个 SATA 、SAS 、NVMe 控制器，通常有额外成本，如果你机器上本来就有这些控制器，而且接口有富裕，就没必要额外用 USB 的。

@standin000 两个问题。
首先一般说的 HBA 卡实际上是 SAS 控制器，就是负责将 PCIe 协议转成 SAS 协议。而 M.2 接口通常是 PCIe 协议或 SATA 协议，如果是 PCIe 协议就是直接连接 PCIe 接口（可能需要 PCIe 拆分卡），如果是 SA 协议就是连接 SATA 控制器；也就是说一般不需要 HBA 卡，因为协议不一样。

硬盘的功耗跟接口关系不大，得实际看硬盘产品的官方手册里的额定功率，SSD 用高速主控和大容量闪存阵列也可以很吃电。常见企业级 M.2 产品功率在 4W-15W ，家用级机械硬盘功率在 5W-14W ；企业级机械硬盘以希捷银河 x18 为例，满载在 9W 左右。HBA 卡不同信号功率也不一样，在 6W 到 26W 。机械硬盘可以通过停转休眠来显著降低功耗，SSD 也有的型号具有断电休眠技术，具体看产品手册是不是有这些节能特性。

题外话，M.2 产品目前相对来说比较贵，如果决定用全闪方案，可以看看 U.2 口（通常也是 PCIe 协议）的产品，可能可以便宜，性能一样。

@sicifus #41
建议第 2 项加快照，可以保留最近几次备份的快照，避免数据损坏后自动进行了备份。

unRAID 对我来说是，确定自己的需求场景可以使用 MergerFS+SnapRAID 满足的情况下，的一个更可靠的替代方案。目前用了两个多月，明显感觉 unRAID 比之前我自己在 Debian 上搭建的 MergerFS+SnapRAID 更稳定耐艹，我上次换了硬盘笼之后已经稳定运行 20 天了。

说明书基本都写了，禁忌情况、药理毒理、药代动力学。

更深层次的药物互相作用问题估计得有专业的医学知识和可靠的化验数据才能评估，一般 OTC 药应该问题不大，真有疑问去找个医生问吧。

给备份盘加快照即可。

我是每天定时将重要数据增量备份到备份盘上，备份盘用 btrbk 脚本自动打快照，保留最近 7 天的快照，快照是只读的，正常的写入操作是无法覆盖的，只有手动删除快照或者格式化才有影响。

算便一台淘汰的 PC 就可以吧，开个 SMB 服务。
有的路由器系统自带 SMB1 ，小米摄像头可以搜到，USB 插移动硬盘/硬盘盒就可以。

用过很多年的 MergerFS+SnapRAID 方案，分享几个坑。

1. SnapRAID 进行奇偶校验同步的时候要求文件不能正在被写入，所以只适用于冷数据。
2. SnapRAID 的原理是每块盘上的数据块进行奇偶校验，所以在 1 块校验盘的情况下，当一块盘坏了的时候，想要恢复数据，就要确保其他盘上的数据仍然是上一次奇偶校验同步的版本，但如果在上一次奇偶校验同步之后其他盘的数据发生了变化，那么这些变化的数据块就无法恢复了（可能仍然可以恢复其他未变化的数据块的数据）。也就是说发生多盘修改文件的情况下，被修改的这些文件可能就会随着硬盘损坏而丢失了。需要对硬盘组的使用方式进行规划，比如每两次校验同步之间确保只在一块硬盘上修改数据，需要在其他盘上修改数据之前先进行奇偶校验同步。
3. MergerFS 是基于 FUSE ，所以要关注 FUSE 本身的短板，以及你目前系统上的 FUSE 是否存在 bug 。
4. 我遇到过两段时间 MergerFS 频繁挂掉的情况，MergerFS 的挂载点会提示 input/output error ，需要重启或重新挂载才能解决。跟 MergerFS 开发者交流过，很难 debug 定位到问题。根据我的观察是当打开状态的文件数量超过 3000 之后就很容易挂掉，不知道是我硬盘 IOPS 跟不上，还是 FUSE 有 Bug 。

建议数据分冷热；假设你的热数据是小部分，那么可以热数据用 RAID-1 等镜像方案；冷数据用 MergerFS+SnapRAID 备份方案，如你画的图写满一块硬盘再写下一块。

单盘容量限制理论上是文件系统方面的限制，不过现代文件系统基本都很难达到这种限制。如果厂商对单盘容量进行了限制，可能是因为对设备系统进行测试后认为系统在单盘大于某个容量后会导致产品使用体验下降，又或是显著加大了售后服务的难度。

不过话说回来我并不推荐用超大容量的硬盘，一旦硬盘故障了，恢复数据需要很长的时间，如果采用奇偶校验备份的方式，在超长时间的恢复过程中会有较大概率再坏盘，导致奇偶校验失效。

如果主板有 PCIe x8/x16 槽可以考虑 HBA 卡+硬盘笼，我用了浪潮服务器上拆下来的 HBA 卡和 12 盘位硬盘笼，很便宜。

P.S. 我在后来评估认为 SnapRAID 不是很符合我个人的需求，转而去使用实时奇偶校验的 unRAID 方案了，当然 unRAID 也有它自己的短板。

升级驱动和降低内核版本试试。

ssh 两部分比较占性能，一个是加密，另一个是压缩。你看看是不是加密算法硬件支持不好或者太复杂；然后看看是不是硬件跑压缩性能不够，带宽够大的话把压缩关了试试。

根据之前调研的压测数据来看，ssh 还是比 smb 性能要好的，当然比不过不加密的协议如 nfs ，如果你确保网络环境安全的话也可以考虑 nfs 。

另外 i 也可以看看是不是远端或本地的磁盘 IO 有问题，比如碎片太多。

小于等于这个逻辑就是错的，因为并没有完全覆盖时间段，除非业务能接受没覆盖的那一部分被排除在外。