[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-btrfs
Subject:    Re: kvm bug, guest I/O blk device errors when qcow2 backing file is on Btrfs
From:       Chris Mason <clm () fb ! com>
Date:       2015-03-23 21:13:35
Message-ID: 20150323211334.GA11155 () ret ! masoncoding ! com
[Download RAW message or body]

On Mon, Mar 23, 2015 at 02:01:41PM -0600, Chris Murphy wrote:
> I can't tell if this is a kvm virtio blk device regression, with
> cache=none and cache=directsync, or if it's a Btrfs regression.
> 
> The summary is that on a host using (Fedora) kernel 3.18.9, 3.19.2, or
> any 4.0.0 kernel, with qcow2 on Btrfs, and either cache=none or
> directsync, the guest Linux OS experiences many I/O blk device errors.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1204569
> 
> If I put the qcow2 on XFS, the problem doesn't happen.
> 
> If I keep the qcow2 on Btrfs, and change the cache= to writeback,
> writethrough, or unsafe, the problem doesn't happen.
> 
> It happens with either qcow2 compat 0.10 or 1.1. Raw files were not
> tested. And block devices other than virtio were not tested.
> 
> In the guest, all file systems experience this and complain, some more
> than others. Btrfs is most tolerant mainly reporting write errors but
> completes an OS installation; ext4 complains a lot but also completes
> an OS installation; XFS complains and eventually gives up with a
> hardware I/O error and the OS installation fails.
> 
> I did this test maybe two years ago and this combination was safe at that time.

The last time we tracked down a similar problem, Josef found it was only
on windows guests.  Basically he tracked it down to buffers changing
while in flight.  I'll take a look.

-chris

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]