[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC] Disk integrity in QEMU
From: |
Daniel P. Berrange |
Subject: |
Re: [Qemu-devel] [RFC] Disk integrity in QEMU |
Date: |
Fri, 10 Oct 2008 10:58:29 +0100 |
User-agent: |
Mutt/1.4.1i |
On Fri, Oct 10, 2008 at 11:16:05AM +0200, Avi Kivity wrote:
> Anthony Liguori wrote:
>
> [O_DSYNC, O_DIRECT, and 0]
>
> >
> >Thoughts?
>
> There are (at least) three usage models for qemu:
>
> - OS development tool
> - casual or client-side virtualization
> - server partitioning
>
> The last two uses are almost always in conjunction with a hypervisor.
>
> When using qemu as an OS development tool, data integrity is not very
> important. On the other hand, performance and caching are, especially
> as the guest is likely to be restarted multiple times so the guest page
> cache is of limited value. For this use model the current default
> (write back cache) is fine.
It is a myth that developers dont' care about data consistency / crash
safety. I've lost countless guest VMs to corruption when my host OS
crashed & its just a waste of my time. Given the choice between
likely-to-corrupt and not-likely-to-corrupt, even developers will
want the latter.
> The 'causal virtualization' use is when the user has a full native
> desktop, and is also running another operating system. In this case,
> the host page cache is likely to be larger than the guest page cache.
> Data integrity is important, so write-back is out of the picture. I
> guess for this use case O_DSYNC is preferred though O_DIRECT might not
> be significantly slower for long-running guests. This is because reads
> are unlikely to be cached and writes will not benefit much from the host
> pagecache.
>
> For server partitioning, data integrity and performance are critical.
> The host page cache is significantly smaller than the guest page cache;
> if you have spare memory, give it to your guests. O_DIRECT is
> practically mandataed here; the host page cache does nothing except to
> impose an additional copy.
>
> Given the rather small difference between O_DSYNC and O_DIRECT, I favor
> not adding O_DSYNC as it will add only marginal value.
>
> Regarding choosing the default value, I think we should change the
> default to be safe, that is O_DIRECT. If that is regarded as too
> radical, the default should be O_DSYNC with options to change it to
> O_DIRECT or writeback. Note that some disk formats will need updating
> like qcow2 if they are not to have abyssal performance.
Absoutely agree that the default should be safe. I don't have enough
knowledge to say whether O_DIRECT/O_DSYNC is best - which also implies
we should choose the best setting by default, because we can't expect
users to know the tradeoffs either.
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, (continued)
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Aurelien Jarno, 2008/10/10
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Anthony Liguori, 2008/10/10
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Paul Brook, 2008/10/10
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Anthony Liguori, 2008/10/10
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Paul Brook, 2008/10/10
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/10
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Jens Axboe, 2008/10/17
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/19
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Aurelien Jarno, 2008/10/10
Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Avi Kivity, 2008/10/10
- Re: [Qemu-devel] [RFC] Disk integrity in QEMU,
Daniel P. Berrange <=
Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Anthony Liguori, 2008/10/10
Re: [Qemu-devel] [RFC] Disk integrity in QEMU, Mark Wagner, 2008/10/11