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

[Jamie Lokier <jamie@shareable.org>]

Anthony Liguori wrote:
> >perhaps I'm wrong but I think O_DSYNC (in fact O_SYNC for linux) will
> >impact host filesystem performance, at least with ext3, because the
> >synchronicity is done through the commit of the journal of the whole
> >filesystem:
> >  
> 
> Yes, but this is important because if the journal isn't committed, then 
> it's possible that while the data would be on disk, the file system 
> metadata is out of sync on disk which could result in the changes to the 
> file being lost.
> 
> I think that you are in fact correct that the journal write is probably 
> unnecessary overhead in a lot of scenarios but Ryan actually has some 
> performance data that he should be posting soon that shows that in most 
> circumstances, O_DSYNC does pretty well compared to O_DIRECT for write 
> so I don't this is a practical concern.

fsync on ext3 is whacky anyway.  I haven't checked what the _real_
semantics of O_DSYNC are for ext3, but I would be surprised if it's
less whacky than fsync.

Sometimes ext3 fsync takes a very long time, because it's waiting for
lots of dirty data from other processes to be written.  (Firefox 3 was
bitten by this - it made Firefox stall repeatedly for up to half a
minute for some users.)

Sometimes ext3 fsync doesn't write all the dirty pages of a file -
there are some recent kernel patches exploring ways to fix this.

Sometimes ext3 fsync doesn't flush the disk's write cache after
writing data, despite barriers being requested, if only dirty data
blocks are written and there is no inode change.

-- Jamie