[Top][All Lists]

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

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

From: Aurelien Jarno
Subject: Re: [Qemu-devel] [RFC] Disk integrity in QEMU
Date: Fri, 10 Oct 2008 17:48:55 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Fri, Oct 10, 2008 at 07:26:00AM -0500, Anthony Liguori wrote:
> Aurelien Jarno wrote:
>> On Thu, Oct 09, 2008 at 12:00:41PM -0500, Anthony Liguori wrote:
>> [snip]
>>> So to summarize, I think we should enable O_DSYNC by default to 
>>> ensure  that guest data integrity is not dependent on the host OS, 
>>> and that  practically speaking, cache=off is only useful for very 
>>> specialized  circumstances.  Part of the patch I'll follow up with 
>>> includes changes  to the man page to document all of this for users.
>>> Thoughts?
>> While I agree O_DSYNC should be the defaults, I wonder if we should keep
>> the current behaviour available for those who want it. We can imagine
>> the following options:
>>   cache=off  O_DIRECT
>>   cache=read O_DSYNC         (default)
> Or maybe cache=off, cache=on, cache=wb.  So that the default was  
> cache=on which is write-through, or the user can choose write-back 
> caching.
> But that said, I'm concerned that this is far too confusing for users.   
> I don't think anyone is relying on disk write performance when in  
> write-back mode simply because the guest already has a page cache so  
> writes are already being completed instantaneously from the  
> application's perspective.

Some of my setups rely on host cache. I am using a swap partition for
some guests in order to increase the available "memory" (some platforms
in qemu are limited to 256MB of RAM), and it that case I don't care 
about data integrity

  .''`.  Aurelien Jarno             | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   address@hidden         | address@hidden
   `-    people.debian.org/~aurel32 | www.aurel32.net

reply via email to

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