Re: Got 10 csum errors according to dmesg but 0 errors according to dev stats

[Philip Seeger <p0h0i0l0i0p@gmail.com>]

The host filesystem (where the virtual hdd is stored) is ZFS (no 
errors). It's a bit slower recently because I am moving a lot of data 
around while other vms are running. But that shouldn't be a problem.

This Arch vm appears to be the only one having problems. Again, I have 
even scrubbed one other vm, which also uses btrfs (but 3.19, not 4.0) 
and found no errors. This is the vm from which I have copied the 11 GB 
directory, which now keeps getting corrupted in the Arch vm.

I'd just like to repeat that I have copied one directory from an older 
vm, which uses btrfs, to a new Arch vm, which also used btrfs, and while 
that older vm has worked fine (still does), the same files in that 
copied directory are getting corrupted in the new Arch vm...

The bug report mentions Gnome Boxes, but I'm using VirtualBox. Don't 
know if both are affected in the same way.
If it makes a difference: The Arch vm has an IDE controller (host cache 
enabled) for the virtual optical drive and one SATA controller (host 
cache disabled) for the virtual hard drive.

I will try to get this vm in a healthy state again by deleting all 
affected files and copying them back again.

Also, should I try to use a specific mount option, maybe a lower commit 
interval?


Philip

On 05/12/2015 03:37 AM, Chris Murphy wrote:
> There are two file systems involved, guest and host. What are their
> file systems? I know one of them is Btrfs but I can't tell if they're
> both Btrfs.
>
> There is a regression somewhere, I don't know where yet, when libvirt
> cache=none or cache=directsync, and the disk image (qcow2 in my case)
> is on Btrfs. The guest file system doesn't matter, it'll eventually
> spew some corruption related errors.
> https://bugzilla.redhat.com/show_bug.cgi?id=1204569
>
>
> Chris Murphy
> --
> 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