qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [RFC PATCH 2/2] iotests: add 222 to test b


From: Kashyap Chamarthy
Subject: Re: [Qemu-devel] [Qemu-block] [RFC PATCH 2/2] iotests: add 222 to test basic fleecing
Date: Wed, 27 Jun 2018 14:28:15 +0200
User-agent: Mutt/1.9.2 (2017-12-15)

On Wed, Jun 27, 2018 at 01:51:59AM -0400, John Snow wrote:

[...]

FWIW, I would also add a little blurb in the commit message about what
"fleecing" exactly is.  Something along the lines of: 

    "It provides an NBD export that serves you a (read-only?)
    point-in-time (PIT) snapshot of a disk."  

I'm sure you can come up with better phrasing.

> > The test looks valid - you are definitely reading data over NBD from the
> > point in time that you started the blockdev-backup job, even while the
> > source image continues to be modified.
> > 
> >> +    for p in overwrite:
> >> +        cmd = "write -P%s %s %s" % p
> >> +        log(cmd)
> >> +        log(vm.hmp_qemu_io(srcNode, cmd))
> >> +
> >> +    log('')
> >> +    log('--- Verifying Data ---')
> >> +    log('')
> >> +
> >> +    for p in patterns:
> >> +        cmd = "read -P%s %s %s" % p
> >> +        log(cmd)
> >> +        assert qemu_io_silent('-r', '-f', 'raw', '-c', cmd, nbd_uri)
> >> == 0
> > 
> > Perhaps additional steps would be to then stop the NBD export, stop the
> > block job, delete the tgtNode fleecing file, then stop qemu, and finally
> > check that the overwritten patterns correctly show up in the source
> > image (that is, also prove that we can tear down a job, and that the
> > overwrites worked).  And we may want to enhance this test (or use it as
> > a starting point to copy into a new test) to play with persistent dirty
> > bitmaps thrown into the mix as well.  But what you have is already a
> > great start to prevent regressions, so:
> > 
> 
> Good suggestions. I'm working toward throwing bitmaps in now, but
> actually cleaning up the VM properly and stopping the NBD server and
> testing some of the latter-half paths would be nice. This was just a bit
> of an RFC to get the bits out there sooner rather than later.

Yeah, they can be added later on.  For this test, you can just get away
by cleaning up the VM and the NBD export: log(vm.qmp("nbd-server-stop").

With that: 

    Reviewed-by: Kashyap Chamarthy <address@hidden>

[...]

-- 
/kashyap



reply via email to

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