Re: superblock checksum mismatch after crash, cannot mount

[Duncan <1i5t5.duncan@cox.net>]

Florian Gamböck posted on Sat, 23 Aug 2014 10:38:47 +0200 as excerpted:

> Am 23.08.2014 07:27, schrieb Duncan:
>> btrfs-show-super is your tool for inspecting the superblocks.  [...]
>> Then use btrfs rescue super-recover

> Yes, show-super told me, that the first super block did "NOT MATCH", but
> the second one seemed to be in order ("MATCHED"). The SD card is 16 GiB
> big, so there was no third super block.
> 
> Rescue also listed the first one as bad and the second one as good and
> it seemed to run successfully, no errors whatsoever.

Good so far, but...

> However, after "recovering", every single partition on the card broke.
> There were three partitions: 1 = fat32 ("/boot"), 2 = swap, 3 = btrfs
> ("/"). Naturally I ran the rescue command on partition 3, I hope that
> was not a mistake. Afterwards, as I said, none of the partitions were
> recognized anymore. Not even btrfs recognized the third partition.

That is strange.  Was the partition table still recognized?  Had you used 
mbr or gpt partitioning (I'm presuming the pi handles them, of course, I 
don't know a lot about pi/arm).

FWIW these days I use gpt because it keeps one checksummed copy at each 
end of the device for better reliability, and of course also because it 
does away with primary/secondary/logical partition worries and allows 
partition names/labels (as distinct from filesystem labels), but I have 
literally /no/ idea whether pi supports it as I've never worked with a pi.

I can't think of any scenario that would screw up all the partitions  
unless the partition table was damaged and/or unless the firmware was 
buggy and basically scrambled things.  It's almost as if the superblock 
fix landed in the middle of the partition table (maybe 64 KiB into the 
entire SD card, is that still partition table?) instead of at the 64 KiB 
mark into what would have been partition 3, the btrfs partition, but if 
it was reading the second one as good, it must have gotten the right 
partition to do that, in which case it couldn't be that you simply typoed 
and didn't include the digit.

I can't personally rule out a bug in btrfs rescue as I've never used that 
tool myself, but one this severe?  Hard to imagine, yet /something/ 
screwed up. 

Weird.

Anyway, were it me, I'd consider that sdcard suspect (bad firmware) until 
I could pin down what it did a bit better, because something implausible 
just happened, and that's as plausible an explanation as anything else 
we've got.

> Since I've thought I messed up entirely, I just gave up, re-formatted
> the card and let my backups do the job.

At that point, that's what I would have done too, with the caveat about 
considering the card suspect for the time being, and being sure it's 
/regularly/ backed up in case it scrambles again.

> It's quite annoying though, how often I get those problems. May it be
> that the Raspberry Pi is too slow to let btrfs do its background magic,
> may it be that btrfs is not that suitable for SD cards (in my case it's
> a class 10 microSDHC, 16GiB), or may it be that btrfs is still not that
> reliable when it comes to "unclean" shutdowns.

I'd guess a mix of the above.  There's some recent research at how poor 
certain solid state devices are at handling power cuts.  Someone here 
probably has a link or google it.  Having work on one partition scramble 
others certainly seems like bad firmware to me, tho I'm no expert.  But 
btrfs' write patterns are surely about as far from the fat many of these 
devices were designed for as it gets, so btrfs may well be stressing it 
quite a bit as well.

I'd also try to compare notes with other pi users and see if they're 
noting problems with the pi and btrfs as well.  I'm entirely clueless in 
that regard, but I read enough about them to at least know they have a 
rather large and active user community, so you can't be the first to have 
tried it.  Someone's gotta have some experience to share.

The other possibility I guess is to try a different brand and spec of 
card, to see if that makes any difference.  I just don't know at this 
point, so it's all in-play ATM.

> Nevertheless, I will keep your explanations around for future reference,
> they were really helpful! Thanks again!

=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman