[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 1/3] qemu-xen-traditional: use O_DIRECT to open disk images for IDE
Ian Campbell writes ("Re: [Xen-devel] [PATCH 1/3] qemu-xen-traditional: use O_DIRECT to open disk images for IDE"): > commit 82787c6f689d869ad349df83ec3f58702afe00fe > Author: Ian Jackson <ian.jackson@xxxxxxxxxxxxx> > Date: Mon Mar 2 11:21:51 2009 +0000 > > Override default cache mode for disk images to write-back > > Upstream qemu changed the default cache mode to write-through (ie, > O_DSYNC) which is much slower. We do not need this as we have > explicit control of cacheing with the IDE cache control commands. ... OK, so the reason for this is as follows: There are IDE commands for controlling cacheing in the disk. These are the commands 0x02 and 0x82 (near l.2666 of hw/ide.c in qemu-xen-unstable). If the host has enabled the write cache, the disk is allowed to buffer written data in its own ram. The host is expected to either disable the cache, or flush the cache (WIN_FLUSH_CACHE, near l.2717) as and when appropriate. We implement this in qemu-xen-unstable as follows: The bdrv_write calls are expected to be write-back cached. The cache enable/disable commands set a variable write_cache in the ide code. If write_cache is 0, we run bdrv_flush after each write. In any case we run bdrv_flush when we get a cache flush command. bdrv_flush calls, effectively, fsync(). So I think qemu-xen-unstable the use of write-back cacheing for bdrv_write is correct. (Apart from the wrinkle that the emulated drive cache, write_cache, is enabled by default - but I wouldn't be surprised if that accurately emulated the behaviour of real disks.) How is this done in qemu-upstream ? Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |