Open richardbrodie opened 1 week ago
Alright, so I decided to try downgrading bcachefs-tools to 1.7.0 and giving it another try and lo and behold, it worked! So this seems like it might just be a tools bug in 1.9.x.
The command I ended up running:
sudo bcachefs mount UUID=55cfeccc-d8b2-4813-b1a4-9ff9212962e7 /mnt/storage \
-o fsck,fix_errors,very_degraded,nochanges,read_only,opts=ro,errors=ro
It took several hours, and spat out a lot of
btree trans held srcu lock (delaying memory reclaim) by more than 31 seconds
warnings, but otherwise seems to have had no further trouble mounting the 7 remaining disks.
I'm backing up the important stuff before I try any more things, and obviously right now there is a lot of this in dmesg (definitely not unexpected at this point):
[111019.630521] bcachefs (55cfeccc-d8b2-4813-b1a4-9ff9212962e7 inum 335745235 offset 1835008): no device to read from [111019.717764] bcachefs (sde inum 134673851 offset 40): data read error: I/O [111019.717841] bcachefs (55cfeccc-d8b2-4813-b1a4-9ff9212962e7 inum 134673851 offset 20480): read error 3 from btree lookup
I have an 8-disk array and after one of my disks died suddenly I'm no longer able to mount it since
/dev/sdh
no longer exists:And in dmesg:
If I try and mount it with
-o very_degraded
it gives the same output. Usingmount.bcachefs
andmount -t bcachefs
give the same output, as does usingUUID=55cfeccc-d8b2-4813-b1a4-9ff9212962e7
.I saw that you can remove a disk by ID so I also tried:
So it seems that would only work if I could mount the array first, which is exactly the problem.
Some extra info: