On Wed, May 20, 2020 at 3:12 PM Jiří Lisický <jiri_lisicky@xxxxxxxxx> wrote: > > > btrfs insp dump-s -fa /dev/loop4 > > superblock: bytenr=65536, device=/dev/loop4 > --------------------------------------------------------- > csum_type 0 (crc32c) > csum_size 4 > csum 0xdc2c003a [match] > bytenr 65536 > flags 0x1 > ( WRITTEN ) > magic _BHRfS_M [match] > fsid 86180ca0-d351-4551-b262-22b49e1adf47 > metadata_uuid 86180ca0-d351-4551-b262-22b49e1adf47 > label sailfish > generation 2727499 > root 30703616 > sys_array_size 226 > chunk_root_generation 2342945 > root_level 1 > chunk_root 20971520 > chunk_root_level 0 > log_root 94920704 There's a log tree being referenced, but in an earlier step you zero'd the log. There might be some data loss for whatever was being written at the time it was last rw mounted. > log_root_transid 0 > log_root_level 0 > total_bytes 14761832448 > bytes_used 5075300352 > sectorsize 4096 > nodesize 4096 > leafsize (deprecated) 4096 > stripesize 4096 > root_dir 6 > num_devices 1 > compat_flags 0x0 > compat_ro_flags 0x0 > incompat_flags 0x3 > ( MIXED_BACKREF | > DEFAULT_SUBVOL ) Must be a very early btrfs-progs. Default these days is 0x161. > / # uname -a > Linux (none) 3.4.108.20190506.1 #1 SMP PREEMPT Sat Nov 30 21:25:45 UTC > 2019 armv7l GNU/Linux > / # btrfs --version > Btrfs v3.16 To attempt a repair, you need something much newer. I suggest 5.6 or 5.6.1 since they're recent. Arch and Fedora Rawhide images will have one of those. I'm not certain v3.16 can reliably tell us what's wrong with the file system, in particular since quotas are enabled. Please update and then repost 'btrfs check' without options. This is promising though: >parent transid verify failed on 94920704 wanted 2727500 found 2727499 Weird - why does it want that generation when the super block says the root tree generation is 2727499? Can you also include output from: # btrfs rescue super -v /dev/ It might be as simple as 'mount -o ro,recovery' with that older kernel if it can roll back to the previous transid. If not, then a more recent btrfs progs might be able to confirm whether the older state can be repaired. That looks like this: # btrfs check /dev/ # btrfs check -r 48250880 /dev/ # btrfs check -r 114339840 /dev/ # btrfs check -r 102043648 /dev/ # btrfs check -r 90173440 /dev/ The first two are most likely to succeed. All of these are still read only, gathering information. There are no repairs yet even though you're working on a backup image (good idea). -- Chris Murphy
