On Tue, Mar 10, 2020 at 12:38 AM Swâmi Petaramesh <swami@xxxxxxxxxxxxxx> wrote: > > [root@zafu ~]# btrfs check -b /dev/sdb1 |& head -64 > [1/7] checking root items > [2/7] checking extents > ref mismatch on [3819245568 4096] extent item 1, found 0 > incorrect local backref count on 3819245568 root 257 owner 736217 offset > 0 found 0 wanted 1 back 0x55f5e4931c00 > backref disk bytenr does not match extent record, bytenr=3819245568, ref > bytenr=0 > backpointer mismatch on [3819245568 4096] > owner ref check failed [3819245568 4096] > ref mismatch on [3819421696 4096] extent item 1, found 0 > incorrect local backref count on 3819421696 root 257 owner 736218 offset > 0 found 0 wanted 1 back 0x55f5e49327e0 > backref disk bytenr does not match extent record, bytenr=3819421696, ref > bytenr=0 > backpointer mismatch on [3819421696 4096] > owner ref check failed [3819421696 4096] > ref mismatch on [3821916160 4096] extent item 1, found 0 > incorrect local backref count on 3821916160 root 257 owner 736219 offset > 0 found 0 wanted 1 back 0x55f5e1ee28e0 > backref disk bytenr does not match extent record, bytenr=3821916160, ref > bytenr=0 > backpointer mismatch on [3821916160 4096] > owner ref check failed [3821916160 4096] ... Maybe some extent tree corruption. I'm thinking that the older kernel without an extensive tree checker won't care, and eventually things may get worse and unworkable again. But it might work for a while? *shrug* Maybe Qu has some idea. It's possible there's more than one power loss event, and that the problem is cumulative. If it were just one time, I'd expect that zeroing the log and mounting with backuproot would completely clear the problem, because you'd go back to a good extent tree state. So I think there's a good chance of prior problems, and that also makes it more difficult to fix. What kernel version was it at the time of the problem? I see btrfs-progs 4.15.1 If you boot from Arch and use btrfs-progs 5.4.1 might fix this problem, but it's about the heaviest hammer there is, and could totally break the file system. btrfs check --init-extent-tree So I wouldn't use it until Qu says it's OK; or you get to a moment with enough time to try to fix and and reformat/reinstall if the fix breaks it totally. As for how to avoid the problem, it may be an old bug (or more than one) in that particular kernel era. Or it might be the storage isn't honoring fua/fsync correctly. Hard to say. I know Btrfs has the potential to be crash safe, because I've got a system I've forced power off over 100 times while compiling, which is doing writes to the Btrfs volume - and Btrfs never complains. But that doesn't mean it's always crash safe - so even though it's a PITA to have a system break due to a kid letting the system crash due to low battery, I think it's a very useful and valid use case. You could change fstab to include these two mount options: flushoncommit,notreelog The first probably won't slow things down, might help improve consistency if there's a crash; where the second will likely make certain things slower because it turns off fsync optimization and requires full sync each time. Next, see about asking Linux Mint community how to run newer kernels. I know that they use Ubuntu packages, so I'd think it's possible to just drop in install new already built Ubuntu kernels like these: https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.5.8/ But ideally it's some opt in for just newer kernels that you can depend on being regularly updated. But I don't know much about how this distribution handles newer kernels. By the way, I mean use new kernels only once the file system is fixed or created new. The new kernels are actually more fussy about existing file system problems, due to the more sophisticated tree checker. -- Chris Murphy
