Hi.
Today I managed to destroy my btrfs root filesystem using the following
sequence of commands:
sync
btrfs balance start -dusage 75 -musage 75 /
sync
fstrim -v /
Shortly after, the kernel spew out lots of messages like the following:
BTRFS warning (device dm-5): csum failed root 257 ino 16634085 off
21504884736 csum 0xd47cc2a2 expected csum 0xcebd791b mirror 1
A btrfs scrub shows roughly 27000 unrecoverable csum errors and lots of
data on that system is not accessible anymore.
I'm running Linux 5.1.2 on an Arch Linux. Their kernel pretty much
matches upstream with only one non btrfs-related patch on top:
https://git.archlinux.org/linux.git/log/?h=v5.1.2-arch1
The btrfs file system was mounted with compress=lzo. The underlying
storage device is a LUKS volume, on top of an LVM logical volume and the
underlying physical volume is a Samsung 830 SSD. The LUKS volume is
opened with the option "discard" so that trim commands are passed to the
device.
SMART shows no errors on the SSD itself. I never had issues with
balancing or trimming the btrfs volume before, even the exact same
sequence of commands as above never caused any issues. Until now.
Does anyone have an idea of what happened here? Could this be a bug in
btrfs?
I have made a copy of that volume so I can get further information out
of it if necessary. I already ran btrfs check on it (using the slightly
outdated version 4.19.1) and it did not show any errors. So it seems
like only data has been corrupted.
Please tell me if I can provide any more useful information on this.
Cheers,
Michael
