On 2019/5/17 上午6:16, Michael Laß wrote: > Hi. > > Today I managed to destroy my btrfs root filesystem using the following > sequence of commands:
I don't have a root fs filled, but a btrfs with linux kernel with
compiled results filling 5G of a total 10G.
I'm using the that fs in my VM to try to reproduce.
>
> sync
> btrfs balance start -dusage 75 -musage 75 /
> sync
> fstrim -v /
Tried the same, while I use --full-blanace for that balance to ensure
all chunks get relocated.
>
> 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.
After above operations, nothing wrong happened in scrub:
$ sudo btrfs scrub start -B /mnt/btrfs/
scrub done for 1dd1bcf6-4392-4be1-8c0e-0bfd16321ade
scrub started at Fri May 17 07:34:26 2019 and finished after 00:00:02
total bytes scrubbed: 4.19GiB with 0 errors
>
> 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.
I'm not sure if it's LUKS or btrfs to blame.
In my test environment, I'm using LVM but without LUKS.
My LVM setup has issue_discards = 1 set.
Would you please try to verify the behavior on a plain partition to rule
out possible interference?
Thanks,
Qu
>
> 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
signature.asc
Description: OpenPGP digital signature
