Am 22.10.2010 14:58, schrieb Anthony Liguori:
On 10/22/2010 03:29 AM, Kevin Wolf wrote:
I agree.
Of course, as Laurent said a while ago, there is no specification for
NBD, so it's hard to say what the intended semantics is.
However, I did have a look at the nbdserver code and it looks as if it
implements something similar to writethrough (namely fsync after each
write) only if configured this way on the server side. qemu-nbd defaults
to writethrough, but can be configured to use cache=none. So with either
server qemu as a client can't tell whether the data is safe on disk or not.
In my book this is a strong argument for refusing to open nbd
connections with anything but cache=unsafe.
On a physical system, if you don't have a battery backed disk and you
enable the WC on your disk, then even with cache=writethrough we're unsafe.
I don't think that's right. O_SYNC should guarantee that the volatile
disk cache is flushed.
Likewise, if you mount your filesystem with barrier=0, QEMU is unsafe.
Yeah, if you do something equivalent to cache=unsafe on a lower layer,
then qemu can't do much about it. Maybe you can apply the same argument
to NBD, even though it's unsafe by default.
QEMU can't guarantee safety. The underlying storage needs to be
configured correctly. As long as we're not introducing caching within
QEMU, I don't think we should assume we're unsafe.
Do we have any place where we can add docs on a per-block format basis?
It would be good to at least mention for each block device how the
backing storage needed to be configured for safety.
docs/block-protocols.txt?