All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <quwenruo.btrfs@gmx.com>
To: Chris Murphy <lists@colorremedies.com>
Cc: Michal Soltys <msoltyspl@yandex.pl>,
	Btrfs BTRFS <linux-btrfs@vger.kernel.org>
Subject: Re: many csum warning/errors on qemu guests using btrfs
Date: Thu, 30 Apr 2020 15:01:53 +0800	[thread overview]
Message-ID: <869f0156-64a9-3b53-001a-57e3efeba157@gmx.com> (raw)
In-Reply-To: <CAJCQCtTwH54CEhcGwv1S9P-i8JOgSHZFg3sKkQxAL1ppeG1cwQ@mail.gmail.com>


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



On 2020/4/30 下午1:01, Chris Murphy wrote:
> On Wed, Apr 29, 2020 at 7:46 PM Qu Wenruo <quwenruo.btrfs@gmx.com> wrote:
>>
>>
>>
>> On 2020/4/30 上午3:21, Chris Murphy wrote:
>>> On Wed, Apr 29, 2020 at 9:45 AM Michal Soltys <msoltyspl@yandex.pl> wrote:
>>>>
>>>> Short update:
>>>>
>>>> 1) turned out to not be btrfs fault in any way or form, as we recreated
>>>> the same issue with ext4 while manually checksumming the files; so if
>>>> anything, btrfs told us we have actual issues somewhere =)
>>
>> Is that related to mixing buffered write with DIO write?
>>
>> If so, maybe changing the qemu cache mode may help?
> 
> I thought this would only happen if the host is Btrfs?

Mixed buffered write with direct IO is known to cause problem, not only
for btrfs, but almost all fses.

> Maybe it's a
> bit crazy but these days I only use Btrfs on Btrfs with cache=unsafe.

Unlike the name, if you're using cache=unsafe, all writes are buffered,
thus you won't hit any csum mismatch problem caused by this.

But you can hit other problems though, e.g. if memory pressure is
forcing some image data to be written, it can break the COW requirement
of the VM (but the file is still completely sane).

> I do lots of VM force quits, never see any problems. I haven't tested
> it, but I think unsafe is quite unsafe if the host crashes/power fails
> while the guest is active. Performance is much better though.
> 
Yeah, host power loss is another problem.

But at least, cache=unsafe actually avoids the csum problem.

Thanks,
Qu


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

  reply	other threads:[~2020-04-30  7:02 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-27 15:23 many csum warning/errors on qemu guests using btrfs Michal Soltys
2020-04-29 15:45 ` Michal Soltys
2020-04-29 19:21   ` Chris Murphy
2020-04-30  1:46     ` Qu Wenruo
2020-04-30  5:01       ` Chris Murphy
2020-04-30  7:01         ` Qu Wenruo [this message]
2020-04-30 13:12       ` Michal Soltys
2020-04-29 19:10 ` Input/output errors (unreadables files) Ferry Toth
2020-04-29 23:45   ` Qu Wenruo
2020-04-30  8:59     ` Ferry Toth

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=869f0156-64a9-3b53-001a-57e3efeba157@gmx.com \
    --to=quwenruo.btrfs@gmx.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=lists@colorremedies.com \
    --cc=msoltyspl@yandex.pl \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.