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 <a...@tuxera.com> > > > > 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. Stefan
signature.asc
Description: PGP signature
