[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-block] [PATCH 1/5] block: Add blklogwrites
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-block] [PATCH 1/5] block: Add blklogwrites |
Date: |
Mon, 4 Jun 2018 10:51:33 +0100 |
User-agent: |
Mutt/1.9.5 (2018-04-13) |
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.
Stefan
signature.asc
Description: PGP signature