On Sat, Mar 20, 2021 at 11:54 PM Dave T <davestechs...@gmail.com> wrote: > > # btrfs check -r 2853787942912 /dev/mapper/xyz > Opening filesystem to check... > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > parent transid verify failed on 2853787942912 wanted 29436 found 29433 > Ignoring transid failure > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > parent transid verify failed on 2853827723264 wanted 29433 found 29435 > Ignoring transid failure > leaf parent key incorrect 2853827723264 > ERROR: could not setup extent tree > ERROR: cannot open file system
btrfs insp dump-t -t 2853827723264 /dev/ > It appears the backup root is already stale. I'm not sure. If you can post the contents of that leaf (I don't think it will contain filenames but double check) Qu might have an idea if it's safe to try a read-write mount with -o usebackuproot without causing problems later. > > What you eventually need to look at is what precipitated the transid > > failures, and avoid it. > > The USB drive was disconnected by the user (an accident). I have other > devices with the same hardware that have never experienced this issue. > > Do you have further ideas or suggestions I can try? Thank you for your > time and for sharing your expertise. The drive could be getting write ordering wrong all the time, and it only turns into a problem with a crash, power fail, or accidental disconnect. More common is the write ordering is only sometimes wrong, and a crash or powerfail is usually survivable, but leads to a false sense of security about the drive. The simple theory of write order is data->metadata->sync->super->sync. It shouldn't ever be the case that a newer superblock generation is on stable media before the metadata it points to. -- Chris Murphy
