qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 0/2] block: Write out internal caches even with


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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]