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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html