chocotan

来晚了，不行了已经

* 坑主要与 EC 有关，其中一部分功能提交 pr 给官方了。我们是从去年这个时候 fork 出来做的二次开发，期间经历了多次集群突然崩溃、突然选举导致服务中断等问题，直到现在才勉强稳定运行。后来我们试图合并官方的代码，发现创建新 volume 的功能疑似被其他人负优化了，就没继续合并了。

* EC 后文件被删除了空间无法释放的问题，我们目前是简单的做了判断——判断 volume 里所有文件都被删除后再删除该 volume 的文件

* Java 版的 EC 我们目前暂时没有精力单独开源出来，等集群稳定后再考虑。

* 一个集群的 master 节点数量设置成 3 个，5 个会增加超时概率，超时了就会触发选举。我们是搭建了两个完全独立的集群，一个无法提供服务的时候会自动切换到另一个

* weed 有预创建 volume 的，但是当 collection 数量过多+高并发的时候，由于它创建 volume 是串行处理、且每创建一个 volume 耗时在百毫秒左右，会导致一部分请求超时（ 10 秒超时）。业务应用需要做重试。

* 副本复制可以，如果空间足够的话建议不要做 EC 。

=========
就在刚刚，我们又发现了一个极端情况下返回上传成功实际文件上传失败的 BUG （与 EC 有关），造成一集群近几个月约 10%共上百 TB 的文件丢失了，这个 BUG 仍然存在于官方的最新版里。

@niz

@niz
我们用 seaweedfs 的一些坑：
1. seaweedfs 的 EC 坑很多——比如不支持 ttl （提了 pr 现在支持了），并且如果用机械盘的话，EC 速度是赶不上文件上传的速度的。我们后来参考 go 源码另外开发了 java 的 ec 任务。还有诸如 EC 后文件删除无法释放空间等问题。
2. 内部大量用到了锁，有几个地方有性能问题，还有并发读写 map 导致 panic 崩溃的问题。
3. 在大量文件写入的情况下，master 节点会突然触发选举，且其选举非常慢——超过 30 秒，且保证可用性的话需要准备两个集群
4. 有大量文件写入、新 volume 生成频繁的时候，创建 volume 的速度赶不上文件写入的速度。

seaweedfs 适合大量小文件，性能是 minio 的几十倍。
minio 适合大文件。它是个黑盒，一旦量大了就懵逼，没任何流量的情况下都能给你磁盘 io 打满。

@chocotan
23 问题解决了，要装 gnome-keyring

刚下载试用
1. 打开文件夹的逻辑太怪了，很不习惯
2. 没法用 deepseek：输入 deepseek 密钥后，按回车不生效，重新打开密钥还要再填
3. github copilot 登录没反应

长续航日常也是充到 80%，只有长途才充满
而且我电池健康度也只剩 89%了

在虚拟机里用 windows 一样卡。

我以前桌面是用 openbox ，后来一直用 awesome wm 到现在十多年
优点大概有：
* 完全的自定义，从快捷键到桌面主题样式，都能够自己调整
* archwiki 很完善，大部分问题都能参考 wiki 解决

不过我不可能推荐别人用 linux 桌面，因为门槛较高。也有不少缺点：
* 开源的图片编辑、音视频编辑等工具很难用，教程也少。最终还是要用 windows 去修图、做视频。
* 一些硬件驱动没有，比如零刻的某些型号缺少网卡驱动
* 显示输出、休眠睡眠、电源管理等，不同机器表现不一样，换个新机器就可能冒出来新的问题。而 windows 这些问题相对较少（只是相对较少，我自从升到 win11 后之后 hdmi 输出就没稳定过）