On Fri, Jun 01, 2018 at 05:24:53PM +0300, Ari Sundholm wrote:
On 06/01/2018 04:32 PM, Stefan Hajnoczi wrote:
On Fri, Jun 01, 2018 at 12:17:19AM +0300, Ari Sundholm wrote:
From: Aapo Vienamo <address@hidden>
Thanks for the patch!
Implements a block device write logging system, similar to Linux kernel
device mapper dm-log-writes. The write operations that are performed
on a block device are logged to a file or another block device. The
write log format is identical to the dm-log-writes format. Currently,
log markers are not supported.
This functionality can be used for fail-safe and fs consistency
testing. By implementing it in qemu, tests utilizing write logs can be
be used to test non-Linux drivers and older kernels.
This patch doesn't implement the same semantics as dm-log-writes, where
only completed writes are logged to make fs consistency testing easier.
If you intend to use it for this purpose, shouldn't it act the same way
as dm-log-writes?
I am not quite sure what you mean. I am not the original author of this
proposed feature, but to me (admittedly with little experience of qemu
internals), it looks like the driver accurately logs the writes and flushes
performed on the guest block device. It intentionally does not concern
itself with when the write actually hits the physical host block device or
file, as we're interested in the direct interactions between a filesystem
driver and the guest block device. The write hitting the various levels of
the host-side caches and devices is left up to the caching mode. But perhaps
there's something obvious I'm not seeing?
Linux dm-log-writes is specific about when logging happens:
* We log writes only after they have been flushed, this makes the log describe
* close to the order in which the data hits the actual disk, not its cache.
So
* for example the following sequence (W means write, C means complete)
*
* Wa,Wb,Wc,Cc,Ca,FLUSH,FUAd,Cb,CFLUSH,CFUAd
*
* Would result in the log looking like this:
*
* c,a,flush,fuad,b,<other writes>,<next flush>
*
* This is meant to help expose problems where file systems do not properly
wait
* on data being written before invoking a FLUSH. FUA bypasses cache so once
it
* completes it is added to the log as it should be on disk.
This patch implements the same on-disk format but the semantics are
different since it doesn't wait for a flush.
If I use dm-log-writes on a linear device-mapper target inside the guest
or on the host, then I would have expected the same output as QEMU's
dm-log-writes, but I think this is not the case.
It's worth at least documenting this quirk.