On Mon, Mar 9, 2020 at 4:30 PM Swâmi Petaramesh <swami@xxxxxxxxxxxxxx> wrote: > > Hi again Chris, and thanks for your kind help, > > Le 06/03/2020 à 19:57, Chris Murphy a écrit : > >> btrfs-progs v4.15.1 > > > That's too old to really be helpful these days. It's not something > > most anyone on an upstream list is keeping track of anymore, what it > > can and can't do, what bugs are fixed, etc. > > Yep but that's the kernel that comes with latest Linux Mint... You can't > expect users to always use latest dev kernels but rather stable ones > that comes with distros. I don't expect users to use anything other than what the distro provides; but users should get support from the distro first, when the distro has decided to keep using older versions. That is their choice. It's fine to ask upstream, I just have no expectation they can ever answer. They are busy enough with mainline and next as it is. > [root@zafu ~]# btrfs-find-root /dev/sdb1 > parent transid verify failed on 8176123904 wanted 183574 found 183573 > parent transid verify failed on 8176123904 wanted 183574 found 183573 > Ignoring transid failure > Superblock thinks the generation is 183574 > Superblock thinks the level is 1 > Found tree root at 8179122176 gen 183574 level 1 OK so that might be OK... but it's running into a stale log tree for some reason. ] > > btrfs insp dump-s /dev/ > > [root@zafu ~]# btrfs insp dump-s /dev/sdb1 > superblock: bytenr=65536, device=/dev/sdb1 > --------------------------------------------------------- > csum_type 0 (crc32c) > csum_size 4 > csum 0x90577c62 [match] > bytenr 65536 > flags 0x1 > ( WRITTEN ) > magic _BHRfS_M [match] > fsid e1d96867-43d3-474e-bca0-665d2c9e0ff2 > metadata_uuid e1d96867-43d3-474e-bca0-665d2c9e0ff2 > label LINUX > generation 183574 > root 8179122176 > sys_array_size 97 > chunk_root_generation 96193 > root_level 1 > chunk_root 64513654784 > chunk_root_level 0 > log_root 8179646464 Yep, this suggests a crash or power fail during fsync. Maybe the first 50 lines of the btrfs check are useful to get an idea what's going on, but without it, it's hard to say what's wrong or what to do. Another option is to zero the log tree, which will mean anything that was being fsync'd at the time is probably lost. It could fix the file system problem, but then result in user space data loss, depending on what was happening at the time of the power loss or crash. # btrfs rescue zero-log /dev/ But with btrfs check complaining, and the super pointing to a log tree, ideally we want the kernel to do log replay. But it sounds like this fails, even with kernel 5.5.8, correct? -- Chris Murphy
