|
From: | Paolo Bonzini |
Subject: | Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with cache=unsafe |
Date: | Sun, 23 Oct 2011 16:33:27 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:7.0) Gecko/20110927 Thunderbird/7.0 |
On 10/22/2011 05:07 PM, Alexander Graf wrote:
On 21.10.2011, at 11:44, Paolo Bonzini wrote:On 10/21/2011 07:08 PM, Kevin Wolf wrote:Avi complained that not even writing out qcow2's cache on bdrv_flush() made cache=unsafe too unsafe to be useful. He's got a point.Why? cache=unsafe is explicitly allowing to s/data/manure/ on crash.Exactly, but not on kill. By not flushing internal caches you're almost guaranteed to get an inconsistent qcow2 image.
This should be covered already by termsig_handler. bdrv_close_all closes all block devices, and qcow2_close does flush the caches.
SIGKILL doesn't give any guarantee of course but it does not in general, even without cache=unsafe; you might get a SIGKILL "a moment before" a bdrv_flush even without cache=unsafe, and get unclean qcow2 metadata.
By not flushing internal caches you're almost guaranteed to get an inconsistent qcow2 image.
Of course the inconsistencies with cache=unsafe will be massive if you don't have a clean exit, but that's expected. If in some cases you want a clean exit, but right now you don't, the place to fix those cases doesn't seem to be the block layer, but the main loop.
Also,1) why should cache=unsafe differentiate an OS that sends a flush from one that doesn't (e.g. MS-DOS), from the point of view of image metadata?
2) why should the guest actually send a flush if cache=unsafe? Currently if (flags & BDRV_O_CACHE_WB) bs->enable_write_cache = 1;covers cache=unsafe. However, in the end write cache enable means "do I need to flush data", and the answer is "no" when cache=unsafe, because the flushes are useless and guests are free to reorder requests.
<shot-in-the-dark>Perhaps what you want is to make qcow2 caches writethrough in cache=unsafe mode, so that at least a try is made to write the metadata</shot-in-the-dark> (even though the underlying raw protocol won't flush it)? I'm not sure that is particularly useful, but maybe it can help me understanding the benefit of this change.
Paolo
[Prev in Thread] | Current Thread | [Next in Thread] |