记一次存储池损毁的恢复经历

前段时间去海鲜市场淘了一个矿龙1250电源给自己的8盘位nas换上了。一开始用的还行，那天跑了下ai生图的时候，矿龙发出了龙吟声，电源啸叫了。当时没在意，第二天发现存储池已经损毁了。看了下硬盘状态，发现有两块状态异常，但是smart报告是正常的。重启nas后存储池还是损毁状态。之前用debian自建nas时候遇到过这种情况。我就通过ssh登录到nas

mdadm -S /dev/md127

停止了raid127。然后通过

mdadm --assemble --force /dev/md127 /dev/sdh1 /dev/sdi1 /dev/sdf1 /dev/sde1 /dev/sdd1 /dev/sdc1 /dev/sda1 /dev/sdb1

重新组装了raid。重启一下nas后，到这里存储池就恢复了。
接下来就是遇到了新的问题了，存储池使用一段时间后，就变成只读状态了。查了下论坛很多人都遇到了同样的问题，但是没有找到解决办法。
通过mount发现是挂载状态变成了ro，raid127状态是active正常的。

systemctl stop docker
systemctl stop smbd
systemctl stop docker.socket
...

我把能想到的服务都停了，然后通过

umount /vol1

卸载卷，但提示设备忙无法卸载。
通过

lsof /vol1

发现是qbittorrent在使用卷，但qbittorrent是通过docker启动，可我的docker服务都停了，qbittorrent也无法停止。
kill进程后又会重新启动。最后只能通过

umount -f /vol1

强制卸载卷后做了个数据块修复

btrfs scrub start /dev/mapper/trim_4d671acd_6acb_41e9_b712_96b90c9fc785-0

修复结果

UUID:             23af5bc7-68ea-4ee7-bd7b-5a6a6b4fbaf1
Scrub started:    Thu May  8 21:17:11 2025
Status:           aborted
Duration:         4:30:00
Total to scrub:   21.93TiB
Rate:             944.63MiB/s
Error summary:    verify=80
  Corrected:      56
  Uncorrectable:  24
  Unverified:     0

修复不成功啊。尝试使用

btrfs check --repair --force /dev/mapper/trim_4d671acd_6acb_41e9_b712_96b90c9fc785-0

结果一直在qbittorrent的config文件上循环，修复失败。
再尝试另一个方法

mkdir -P /mnt/badpool
mount -o ro /dev/mapper/trim_4d671acd_6acb_41e9_b712_96b90c9fc785-0 /mnt/badpool

挂载卷，然后通过

find /mnt/badpool -type f -exec cp -v {} /dev/null \; 2> /root/file.txt

通过/root/file.txt查看损坏文件，然后通过将其删除掉后，再通过

btrfs scrub start /dev/mapper/trim_4d671acd_6acb_41e9_b712_96b90c9fc785-0