From: David Woodhouse <dwmw2@infradead.org>
To: linux-btrfs@vger.kernel.org
Subject: Reading files with bad data checksum
Date: Sun, 10 Jan 2021 11:52:15 +0000 [thread overview]
Message-ID: <1ad3962943592e9a60f88aecdb493f368c70bbe1.camel@infradead.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 1954 bytes --]
I migrated a system to btrfs which was hosting virtual machins with
qemu.
Using it without disabling copy-on-write was a mistake, of course, and
it became horribly fragmented and slow.
So I tried copying it to a new file... but it has actual *errors* too,
which I think are because it was using the 'directsync' caching mode
for block I/O in qemu.
https://bugzilla.redhat.com/show_bug.cgi?id=1204569#c12
I filed https://bugzilla.redhat.com/show_bug.cgi?id=1914433
What I see is that *both* disks of the RAID-1 have data which is
consistent, and does not match the checksum that btrfs expects:
[ 6827.513630] BTRFS warning (device sda3): csum failed root 5 ino 24387997 off 2935152640 csum 0x81529887 expected csum 0xb0093af0 mirror 1
[ 6827.517448] BTRFS error (device sda3): bdev /dev/sdb3 errs: wr 0, rd 0, flush 0, corrupt 8286, gen 0
[ 6827.527281] BTRFS warning (device sda3): csum failed root 5 ino 24387997 off 2935152640 csum 0x81529887 expected csum 0xb0093af0 mirror 2
[ 6827.530817] BTRFS error (device sda3): bdev /dev/sda3 errs: wr 0, rd 0, flush 0, corrupt 9115, gen 0
It looks like an O_DIRECT bug where the data *do* get updated without
updating the checksum. Which is kind of the worst of both worlds, I
suppose, since I also did get the appalling performance of COW and
fragmentation.
In the short term, all I want to do is make a copy of the file, using
the data which are in the disk regardless of the fact that btrfs thinks
the checksum doesn't match. Is there a way I can turn off *checking* of
the checksum for that specific file (or file descriptor?).
Or is the only way to do it with something like FIBMAP, reading the
offending blocks directly from the underlying disk and then writing
them into the appropriate offset in (a copy of) the file? A plan which
is slightly complicated by the fact that of course btrfs doesn't
support FIBMAP.
What's the best way to recover the data?
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 5174 bytes --]
next reply other threads:[~2021-01-10 11:54 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-10 11:52 David Woodhouse [this message]
2021-01-10 12:08 ` Reading files with bad data checksum Forza
2021-01-10 12:36 ` David Woodhouse
2021-01-11 18:56 ` Goffredo Baroncelli
2021-01-10 22:45 ` Chris Murphy
2021-01-11 8:23 ` Nikolay Borisov
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=1ad3962943592e9a60f88aecdb493f368c70bbe1.camel@infradead.org \
--to=dwmw2@infradead.org \
--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;
as well as URLs for NNTP newsgroup(s).