From: "Michael Laß" <bevan@bi-co.net>
To: <linux-btrfs@vger.kernel.org>
Subject: Massive filesystem corruption after balance + fstrim on Linux 5.1.2
Date: Fri, 17 May 2019 00:16:20 +0200 [thread overview]
Message-ID: <297da4cbe20235080205719805b08810@bi-co.net> (raw)
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
next reply other threads:[~2019-05-16 22:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-16 22:16 Michael Laß [this message]
2019-05-16 23:41 ` Massive filesystem corruption after balance + fstrim on Linux 5.1.2 Qu Wenruo
2019-05-16 23:42 ` Chris Murphy
2019-05-17 17:37 ` Michael Laß
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] ` <CAK-xaQYPs62v971zm1McXw_FGzDmh_vpz3KLEbxzkmrsSgTfXw@mail.gmail.com>
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 publicly 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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=297da4cbe20235080205719805b08810@bi-co.net \
--to=bevan@bi-co.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox