After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 746662 - do not use cache=none, causes problems on Btrfs
do not use cache=none, causes problems on Btrfs
Status: RESOLVED DUPLICATE of bug 679837
Product: gnome-boxes
Classification: Applications
Component: general
3.15.x
Other Linux
: Normal critical
: 3.22
Assigned To: GNOME Boxes maintainer(s)
GNOME Boxes maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2015-03-23 18:46 UTC by Chris Murphy
Modified: 2016-03-31 13:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Chris Murphy 2015-03-23 18:46:46 UTC 
gnome-boxes-3.15.91-1.fc22.x86_64

gnome-boxes uses qemu cache=none by default, and when the qcow2 is on Btrfs, this combination causes major I/O block device errors in the guest VM. If the guest VM installation is set to use XFS, eventually XFS gives up and complains of hardware problems and the installation fails.

See bug for the details (lots of dmesg of both host and guest, with specific kernel blk_update_request: I/O errors.
https://bugzilla.redhat.com/show_bug.cgi?id=1204569

Recommend gnome-boxes stop using cache=none, and either not specify it like virt-manager, or use something that works. The description of cache=writeback seems most applicable and it doesn't have this problem.

cache=directsync also has this problem so that's not a good alternate to none.
Comment 1 Zeeshan Ali 2015-03-24 13:49:40 UTC 
cache=none gave us a big boost in our I/O performance and likely played a big role in reducing windows 7 installation from 3 hours to 20 mins. So I'd like to know how other options compare in performance before I could decide to just use them.

In any case, this is a dup of bug#679837, where you can follow the whole discussion and feel free to re-open that one for further discussion on this subject.

*** This bug has been marked as a duplicate of bug 679837 ***
Comment 2 Zeeshan Ali 2015-03-24 13:56:05 UTC 
(In reply to Chris Murphy from comment #0)
> gnome-boxes-3.15.91-1.fc22.x86_64
> 
> gnome-boxes uses qemu cache=none by default, and when the qcow2 is on Btrfs,
> this combination causes major I/O block device errors in the guest VM. If
> the guest VM installation is set to use XFS, eventually XFS gives up and
> complains of hardware problems and the installation fails.
> 
> See bug for the details (lots of dmesg of both host and guest, with specific
> kernel blk_update_request: I/O errors.
> https://bugzilla.redhat.com/show_bug.cgi?id=1204569

Looking at that bug, it seems like its a regression and not that cache=none is not supported on btrfs so the problem needs to be solved where it is and Boxes shouldn't need to work around it, especially if we are unsure of possible performance penalty from the workaround. There is a lot of moving parts in the lower layers and something breaks every now and then so if Boxes would work around them all, it would get out of hand pretty fast.