Re: Massive filesystem corruption after balance + fstrim on Linux 5.1.2

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

[-- Attachment #1.1: Type: text/plain, Size: 2587 bytes --]



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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]