Linux-BTRFS Archive on
 help / color / Atom feed
From: "Michael Laß" <>
To: Chris Murphy <>
Cc: Btrfs BTRFS <>
Subject: Re: Massive filesystem corruption after balance + fstrim on Linux 5.1.2
Date: Fri, 17 May 2019 19:37:49 +0200
Message-ID: <> (raw)
In-Reply-To: <>

> Am 17.05.2019 um 01:42 schrieb Chris Murphy <>:
> Btrfs balance is supposed to be COW. So a block group is not
> dereferenced until it is copied successfully and metadata is updated.
> So it sounds like the fstrim happened before the metadata was updated.
> But I don't see how that's possible in normal operation even without a
> sync, let alone with the sync.

Balance is indeed not to blame here. See below.

> The most reliable way to test it, ideally keep everything the same, do
> a new mkfs.btrfs, and try to reproduce the problem. And then do a
> bisect. That for sure will find it, whether it's btrfs or something
> else that's changed in the kernel. But it's also a bit tedious.
> I'm not sure how to test this with any other filesystem on top of your
> existing storage stack instead of btrfs, to see if it's btrfs or
> something else. And you'll still have to do a lot of iteration. So it
> doesn't make things that much easier than doing a kernel bisect.
> Neither ext4 nor XFS have block group move like Btrfs does. LVM does
> however, with pvmove. But that makes the testing more complicated,
> introduces more factors. So...I still vote for bisect.
> But even if you can't bisect, if you can reproduce, that might help
> someone else who can do the bisect.

I tried to reproduce this issue: I recreated the btrfs file system, set up a minimal system and issued fstrim again. It printed the following error message:

fstrim: /: FITRIM ioctl failed: Input/output error

Now it gets iteresting: After this, the btrfs file system was fine. However, two other LVM logical volumes that are partitioned with ext4 were destroyed. I cannot reproduce this issue with an older Linux 4.19 live CD. So I assume that it is not an issue with the SSD itself. I’ll start bisecting now. It could take a while since every “successful” (i.e., destructive) test requires me to recreate the system.

> Your stack looks like this?
> Btrfs
> LUKS/dmcrypt
> Samsung SSD

To be precise, there’s an MBR partition in the game as well:

MBR partition
Samsung SSD


  reply index

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-16 22:16 Michael Laß
2019-05-16 23:41 ` Qu Wenruo
2019-05-16 23:42 ` Chris Murphy
2019-05-17 17:37   ` Michael Laß [this message]
2019-05-18  4:09     ` Chris Murphy
2019-05-18  9:18       ` Michael Laß
2019-05-18  9:31         ` Roman Mamedov
2019-05-18 10:09           ` Michael Laß
2019-05-18 10:26         ` Qu Wenruo
2019-05-19 19:55           ` fstrim discarding too many or wrong blocks on Linux 5.1, leading to data loss Michael Laß
2019-05-20 11:38             ` [dm-devel] " Michael Laß
2019-05-21 16:46               ` Michael Laß
2019-05-21 19:00                 ` Andrea Gelmini
2019-05-21 19:59                   ` Michael Laß
2019-05-21 20:12                   ` Mike Snitzer
2019-05-24 15:00                     ` Andrea Gelmini
2019-05-24 15:10                       ` Greg KH
     [not found]             ` <>
2019-05-20 13:58               ` Michael Laß
2019-05-20 14:53                 ` Andrea Gelmini
2019-05-20 16:45                   ` Milan Broz
2019-05-20 19:58                     ` Michael Laß
2019-05-21 18:54                     ` Andrea Gelmini
2019-05-28 12:36 ` Massive filesystem corruption after balance + fstrim on Linux 5.1.2 Christoph Anton Mitterer
2019-05-28 12:43   ` Michael Laß

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Linux-BTRFS Archive on

Archives are clonable:
	git clone --mirror linux-btrfs/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-btrfs linux-btrfs/ \
	public-inbox-index linux-btrfs

Newsgroup available over NNTP:

AGPL code for this site: git clone public-inbox