On Wed, Jan 2, 2019 at 5:26 PM b11g <b11g@xxxxxxxxxxxxxx> wrote:
>
> Hi all,
>
> I have several BTRFS success-stories, and I've been an happy user for quite a long time now. I was therefore surprised to face a BTRFS corruption on a system I'd just installed.
>
> I use NixOS, unstable branch (linux kernel 4.19.12). The system runs on a SSD with an ext4 boot partition, a simple btrfs root with some subvolumes, and some swap space only used for hibernation. I was working on my server as normal when I noticed all of my BTRFS subvolumes had been remounted ro. After a short time, I started getting various IO errors ("bus error" by journalctl, "I/O error" by ls etc.). I halted the system (hard reboot), at the reboot the BTRFS partition would not mount. I suspected the corruption to be disk-related, but smartctl does not show any warning for the disk, and the ext4 partition seems healthy.
>
> Those are the kernel messages logged when I attempt to mount the partition:
> Jan 02 23:39:38 nixos kernel: BTRFS warning (device sdd2): sdd2 checksum verify failed on <L> wanted <A> found <B> level 0
> Jan 02 23:39:38 nixos kernel: BTRFS error (device sdd2): failed to read block groups: -5
> Jan 02 23:39:38 nixos systemd[1]: Started Cleanup of Temporary Directories.
> Jan 02 23:39:38 nixos kernel: BTRFS error (device sdd2): open_ctree failed
Do you have the entire kernel message from the previous boot when the
problem started, including I/O errors? We kinda need to see what was
going on leading up to the read only mount, and the bus and I/O
errors. journalctl -b-1 -k should do it, or using journalctl
--list-boots to find it. You can redirect to a file with > and then
attach to the reply if it's small enough, or put it up somewhere like
Dropbox or Google Drive if it's too big.
btrfs rescue super -v /dev/sdd2
btrfs insp dump-s -f /dev/sdd2
Those are reader only. And also try to mount with -o usebackuproot and
if that fails -o ro,usebackuproot is often more tolerant. But that's
for getting data off the volume, it's more useful to know why the file
system broke. And also why btrfs check is failing, given that it's a
current version.
If you get a chance you can take an image, maybe a Btrfs developer
will find it useful to understand why the Btrfs check is failing.
btrfs-image -c9 -t4 -ss <dev> /path/to/fileoutput.image
That is usually around 1/2 the size of file system metadata. It
contains no data and filenames will be hashed.
--
Chris Murphy
