[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] Disk integrity in QEMU

From: Avi Kivity
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
Date: Fri, 10 Oct 2008 11:16:05 +0200
User-agent: Thunderbird (X11/20080723)

Anthony Liguori wrote:

[O_DSYNC, O_DIRECT, and 0]


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.

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.

I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]