On Thu, Jun 17, 2010 at 3:39 PM, Kevin Wolf <kw...@redhat.com> wrote: > Am 17.06.2010 16:19, schrieb Stefan Hajnoczi: >> On Thu, Jun 17, 2010 at 1:03 PM, Kevin Wolf <kw...@redhat.com> wrote: >>> Use bdrv_(p)write_sync to ensure metadata integrity in case of a crash. >> >> Any performance numbers? This change is necessary for correctness but >> I wonder what the performance impact is for users. > > No numbers yet, but as you say we need to do it anyway. It should > definitely be better than any other option that I can think of > (cache=writethrough or some O_DIRECT|O_DSYNC mode) in that it only hurts > performance when metadata is actually changed. As long as we only write > guest data, there is no difference. > > Making it a barrier instead of a flush would probably be better, have > you already had a look at this since we talked about it?
No I haven't seen a userspace barrier solution. I'm not actively working on that at the moment but am keeping an eye out for solutions. I'm not sure what to make of sync_file_range(2), the man page suggests it cannot be relied on since only already allocated blocks will be flushed appropriately. Filesystem metadata changes are not flushed, which is especially problematic for copy-on-write filesystems (according to the man page). Thinking about the performance more, I predict that guest OS installations will slow down but day-to-day usage (especially modifying already allocated blocks) will be alright for the reasons you mentioned. Stefan
