On 2014-08-14 12:09, Marc MERLIN wrote:
> Running 3.15.5, laptop hung overnight, I was forced to reboot with sysrq.
> 
> After that, it wouldn't mount anymore:
> [  689.366125] BTRFS: device label btrfs_pool1 devid 1 transid 237214 /dev/dm-1
> [  716.384377] BTRFS info (device dm-1): disk space caching is enabled
> [  716.566974] BTRFS: detected SSD devices, enabling SSD mode
> [  716.567106] BTRFS: bad tree block start 8622613565695139001 49500766208
> [  716.567220] BTRFS: bad tree block start 10955809011958619003 49500766208
> [  716.567224] BTRFS: failed to read log tree
> [  716.638634] BTRFS: open_ctree failed
> 
> Ok, btrfs-zero-log usually helps with this, but not this time:
> legolas:~# btrfs-zero-log /dev/mapper/disk1 
> Check tree block failed, want=49500766208, have=8622613565695139001
> Check tree block failed, want=49500766208, have=8622613565695139001
> Check tree block failed, want=49500766208, have=10955809011958619003
> Check tree block failed, want=49500766208, have=10955809011958619003
> Check tree block failed, want=49500766208, have=10955809011958619003
> read block failed check_tree_block
> Couldn't setup log root tree
> legolas:~# 
> 
> It's recent:
> legolas:~# btrfs-zero-log 
> usage: btrfs-zero-log dev
> Btrfs v3.14.1
> 
> mount -o ro,recovery /dev/mapper/disk1 /mnt/mnt
> does not work either, but that's expected.
> 
> I can probably use some recovery tools to get data off it, but I already
> have a backup.
> I'd much rather not have to destroy and rebuild this partition.
> 
> Worst thing is that it happened with 3.15 and I had just changed it to
> compress=none (although there was existing data was compresssed).
> 
> Do you have any suggestions on how to repair this partition so that it's
> mountable again?
> 
> This is a good SSD (samsung evo 840), I'm not sure it's to blame for
> corrupting data or writing it out of order and lying to the OS about it.
> If that is not the case, does it mean btrfs is still getting into states
> where it mangles the filesystem in a way that it can't mount it anymore?
> 
> Thanks,
> Marc
> 
I don't think it is likely that the Samsung SSD is to blame, in my
experience Samsung's SSD's are better than almost every other brand
except Intel, and I know that they honor write-barriers correctly.
The likely issue is that the system hung during the process of a commit,
which is one of the few things that I know of that consistently corrupts
the filesystem.  There isn't really anything I know of to prevent it,
except for making your system as stable as possible.
Interestingly, this type of thing is the only issue I've ever had with
BTRFS that wasn't traceable to hardware problems.