Yes, /dev/sda2 mounts successfully.
-- Jude <jdashiel at panix dot com> "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." Ed Howdershelt 1940. On Sun, 12 Nov 2023, Sean Greenslade wrote: > On Sat, Nov 11, 2023 at 11:59:05AM +0000, Paul Dann wrote: > > > I would like to know how to prevent btrfs corruption in the first place. > > > > > > > Use a more stable filesystem? 😂 Really sorry, but you walked right into > > that one. It sucks that it got corrupted, and I believe it's less prone to > > corruption than it used to be, but personally I still avoid it because it's > > only just reaching maturity. I hope you have some backups of anything > > important. > > I would say that the core of btrfs is definitely stable* and usable, and > I use it as the root filesystem on all of my laptops, desktops, servers, > and a few ARM single-board computers. I have never had it randomly > corrupt without there being some failure of the underlying storage, and > in fact I find that btrfs is more likely to show you issues with your > storage early, when you still have the chance to recover things. > > For example, in Jude's post to the btrfs-dev mailing list, this log > line: > > > [ 1.647025] BTRFS info (device sda2): bdev /dev/sda2 errs: wr 0, rd 0, > > flush 0, corrupt 16, gen 0 > > tells you that this particular filesystem has seen 16 silent > corruptions. In other words, the disk returned blocks that were > different from what was written without giving any explicit errors. > Almost no other filesystem will give you that kind of information. > > As an aside to Jude, your message to the btrfs mailing list does not > include any actual error messages. Does the partition actually mount > successfully? If so, then there is likely nothing to repair, and I would > focus on trying to find the cause of the corruptions (typically faulty > RAM or a failing hard drive). > > --Sean > > > * So long as you do not use parity raid or quotas. >
