cpstar

这个“完全不用管数据可用性，只是想把一堆硬盘结合起来获取最大的硬盘可用空间”听起来很像 RAID-0

哪有这么算 120m 的，要是海拔超过 120m ，还挖坑往地下飞啊。。。

想要玩，就按规矩来，没有什么 49 年不 49 年的

我就想知道，没有实际损失，即便去法院，诉讼请求怎么写。然后已经失效的 aksk ，能产生什么样的损失。

甚至猜，最开始只能发送图片，然后为了传输问题，本地重编码，于是程序就是

- 文件先载入到一个图像处理的库，然后压缩之类的，如果不是图片文件，则对象返回一个异常或者空，当年的规则就是不能发

- 然后有了额外图片的需要，不能发的规则注释掉了，但是判断文件的机理还在；

- 再然后有了发原图，于是载入库后，执行了原有压缩的代码，当按下“发原图”之后，还是发送图片的流程只不过加了一个 boolean 默认 false ，压缩的那段逻辑判断 boolean 为 true 则跳过

感觉差不多就是这么一个屎山堆起来的。

而 QQ 当年的逻辑不是发图片，而是发文件，图片是在发文件的逻辑下衍生出来的。

以上是胡思乱想。

微信为了传输或者显示之类的，进行了重编码。最可靠的方法，打一个压缩包。

笑成鹅，正经官方回复

ext 点 to
torrentgalaxy 点 one
uindex 点 org

我就想知道，一旦盘多（>4 盘），是散着用四块盘，还是整合起来用，如果整合起来用，是不是不硬 RAID 就是软 RAID ，前者不说了卡不便宜，配上电池和缓存，软 RAID ，效率高一点的，除了 zfs 还有啥，linux 的 mdadm 效率（写入）不算高，windows server 好像更差。解决了这个问题，上层是什么系统就无所谓了，无非是易用性高低而已。所以，TruNAS ，或者 qnap 的 quts hero 。我用的是 tank 的 1581 和黑威。

补 16#，一旦多盘，没有硬 RAID 的情况下，就是软 RAID ，那就是要看各种软 RAID 方案的磁盘吞吐效率。至于为什么要 RAID ，因为要多盘联合在一起使用，盘越多越需要。

基于这个，选择了 zfs ，以及比 TruNAS 更产品化一层的 qnap ，然后黑了一套。