Jamie Lokier writes ("Re: [Qemu-devel] [PATCH] ide.c make write cacheing controllable by guest"): > However, I notice that it tells the guest that data is committed to > hard storage when the host has merely called fsync().
Yes, that's what fsync is supposed to do. > On Linux (and other host OSes), fdatsync() and fsync() don't always > commit data to hard storage; it sometimes only commits it to the hard > drive cache. (Seriously, just look at fs/ext3/fsync.c; only journal > writes cause the flush, and they aren't done if the inode itself > hasn't changed). As Chris Wedgwood says, I think this is a bug. I was going to quote SuSv3 but sadly it's very vague. > Ideally, the host would provide variation of fdatasync() which flushes > data to hard storage in the same way that kernel filesystem journal > writes can do, and Qemu would use that. Another question arises: do we want bdrv_flush to call (eventually) fsync or fdatasync ? If the latter we need to make sure that we call fsync instead when necessary, for example when a cow file is extended. Ian.