From: Josef Bacik <josef@toxicpanda.com>
To: kreijack@inwind.it
Cc: Josef Bacik <josef@toxicpanda.com>,
Paulo Dias <paulo.miguel.dias@gmail.com>,
linux-btrfs@vger.kernel.org
Subject: Re: qcow2 images make scrub believe the filesystem is corrupted.
Date: Fri, 18 Aug 2017 13:43:57 -0400 [thread overview]
Message-ID: <20170818174356.GA1526@destiny> (raw)
In-Reply-To: <ceb36a9a-b73f-96c1-cb58-24f149b24001@libero.it>
On Fri, Aug 18, 2017 at 06:23:18PM +0200, Goffredo Baroncelli wrote:
> On 08/18/2017 01:39 AM, Josef Bacik wrote:
> [...]
> > This is happening because the app (the guest OS in this case, we saw this a lot
> > with windows guests) is changing the pages while they are in flight. We
> > calculate the checksum of the page before it's written, so if it changes while
> > in flight we'll end up with a csum mismatch.
> >
> > To fix this change kvm to not use O_DIRECT or set NODATASUM on your qcow2 image.
> > You'll have to re-create the image because NODATASUM won't apply to the already
> > invalid checksums. Thanks,
>
> Hi Josef,
>
> could you elaborate: do you are saying that using O_DIRECT is incompatible with DATASUM ?
>
No, I'm saying using O_DIRECT with applications that don't protect in-flight
memory are incompatible with DATASUM. We have no way of making sure nobody
touches the page while we're writing it out, so after we calculate the checksum
any changes to the page are going to cause a checksum mismatch. O_DIRECT are
user space pages, there's nothing we can do to stop user space from doing stupid
things.
The options I looked into before were things like detecting the page had changed
since we calculated the checksum, and re-submitting the write. This punishes
applications that do the right thing (databases for example) by forcing us to
calculate checksums twice.
This is a shit situation because users aren't going to understand this
limitation, and it bites them in the ass with all these weird errors. I think
maybe we need to go back to the double-checksum thing by default, and have a
flag or something for users to set if they know their application behaves
properly. Thanks,
Josef
next prev parent reply other threads:[~2017-08-18 17:43 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-16 1:12 qcow2 images make scrub believe the filesystem is corrupted Paulo Dias
2017-08-16 1:40 ` Qu Wenruo
2017-08-16 1:51 ` Paulo Dias
2017-08-16 2:28 ` Qu Wenruo
2017-08-16 2:46 ` Qu Wenruo
2017-08-16 7:47 ` Qu Wenruo
2017-08-16 23:32 ` Chris Murphy
2017-08-17 8:04 ` Duncan
2017-08-17 19:10 ` Chris Murphy
2017-08-17 20:17 ` Paulo Dias
2017-08-17 20:58 ` Chris Murphy
2017-08-17 23:39 ` Josef Bacik
2017-08-18 16:23 ` Goffredo Baroncelli
2017-08-18 17:43 ` Josef Bacik [this message]
2017-08-18 22:19 ` Goffredo Baroncelli
2017-08-19 13:08 ` Goffredo Baroncelli
2017-08-18 23:29 ` Qu Wenruo
2017-08-18 17:59 ` Liu Bo
2017-08-18 18:25 ` Paulo Dias
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=20170818174356.GA1526@destiny \
--to=josef@toxicpanda.com \
--cc=kreijack@inwind.it \
--cc=linux-btrfs@vger.kernel.org \
--cc=paulo.miguel.dias@gmail.com \
/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).