I'm not sure I'm confident enough to recommend a course of action on this one, but one note from something you said:
On Thu, Jan 28, 2021 at 10:03:08PM +1100, Andrew Vaughan wrote: [...] > Today I did '# btrfs fi resize 4:max /srv/shared' as preparation for a > balance to make the extra drive space available. (The old drives are > all fairly full. About 130 GB free space on each. I initially tried > btrfs fi resize max /srv/shared as the syntax on the manpage implies > that devid is optional. Since that command errored, I assume it > didn't change the filesystem). The devid is indeed optional, but it then assumes that you mean device 1 (which is what it is on a single-device FS). It looks like your FS, for historical reasons, no longer has a device 1, hence the error. That should be completely harmless. [...] > # uname -a > Linux nl40 5.10.0-2-amd64 #1 SMP Debian 5.10.9-1 (2021-01-20) x86_64 GNU/Linux > > # mount -t btrfs /dev/sdd1 /mnt/sdd-tmp > mount: /mnt/sdd-tmp: wrong fs type, bad option, bad superblock on > /dev/sdd1, missing codepage or helper program, or other error. > > # dmesg | grep -i btrfs > [ 5.799637] Btrfs loaded, crc32c=crc32c-generic > [ 6.428245] BTRFS: device label samba.btrfs devid 8 transid 1281994 > /dev/sdb1 scanned by btrfs (172) > [ 6.428804] BTRFS: device label samba.btrfs devid 5 transid 1281994 > /dev/sdd1 scanned by btrfs (172) > [ 6.429473] BTRFS: device label samba.btrfs devid 4 transid 1281994 > /dev/sde1 scanned by btrfs (172) > [ 2004.140494] BTRFS info (device sde1): disk space caching is enabled > [ 2004.790843] BTRFS error (device sde1): super_total_bytes > 22004298366976 mismatch with fs_devices total_rw_bytes 22004298370048 > [ 2004.790854] BTRFS error (device sde1): failed to read chunk tree: -22 > [ 2004.805043] BTRFS error (device sde1): open_ctree failed > > Note that drive identifiers have changed between reboots. I haven't > seen that on this system before. It happens sometimes. Sometimes between kernels, sometimes changed hardware responds slightly faster than the previous device. Sometimes devices get bumped along by having something new attached to an earlier controller in the enumeration sequence. I've seen machines that have had totally stable hardware for years suddenly decide to flip enumeration order on one reboot. I wouldn't worry about it. :) The good news is I don't see any of the usual horribly fatal error messages here, so it's probably fixable. > Questions > ========= > > Is btrfs rescue fix-device-size <device> considered the best way to > recover? Should I run that once for each device in the filesystem? I'm not confident enough to answer anything more than "probably" to both of those. > Do you want me to run any other commands to help diagnose the cause > before attempting recovery? Looks like a fairly complete report to me (but see above). Hugo. -- Hugo Mills | Be pure. hugo@... carfax.org.uk | Be vigilant. http://carfax.org.uk/ | Behave. PGP: E2AB1DE4 | Torquemada, Nemesis
