Re: [Qemu-block] Disconecting /dev/nbdX leaves stale partitions and device

[Nir Soffer]

On Sat, Jul 28, 2018 at 12:13 PM Richard W.M. Jones <address@hidden> wrote:

On Sat, Jul 28, 2018 at 12:34:29AM +0300, Nir Soffer wrote:
> > $ time bash -c '(qemu-img convert -p -n fedora-27.img
> > nbd:unix:/var/tmp/sock; sync)'
> >     (100.00/100%)
> >
> > real    0m9.555s
> > user    0m0.143s
> > sys     0m0.578s
> >
> >
> > $ time bash -c '( cp fedora-27.img output2; sync )'
> >
> > real   0m9.254s
> > user   0m0.005s
> > sys    0m0.846s
> >
> >
> > Maybe I'm making a mistake in my test somewhere?
> >
>
> Looks like you test kernl page cache.

Even though I'm running sync as part of the test?

Using host page cache behaves differently and is less predictable.

For copying/uploading images using direct I/O is more consistent and usually

faster.

Also sync should not be needed, qemu-img is flushing at the end. You can also

see how progress advance very fast writing to the page cache, and then we 

see several seconds wait while flushing the changes to disk.

> I was testing with qemu-nbd -n
> since we always disable the cache when writing or reading from shared
> storage.

And the other significant difference is you're using block devices,
which is of course important for oVirt.

I retested on my machine using an LV backed by an SSD.  Not sure if it
supports efficient trimming however, I suspect it might not.

nbdkit (with your patch - thanks!):

$ sudo ./nbdkit file file=/dev/vg_trick_ssd/tmp_nbd_test -f -U /var/tmp/sock &
$ time sudo bash -c "qemu-img convert -n -p fedora-27.img nbd:unix:/var/tmp/sock ; sync"
    (100.00/100%)

real    0m54.713s
user    0m0.189s
sys     0m1.832s

This is not using fallocate() because the FALLOC_FL_* macros are not included:

https://www.redhat.com/archives/libguestfs/2018-July/msg00083.html

 

qemu-nbd, but not using -n option:

$ sudo qemu-nbd /dev/vg_trick_ssd/tmp_nbd_test -k /var/tmp/sock &
$ time sudo bash -c "qemu-img convert -n -p fedora-27.img nbd:unix:/var/tmp/sock ; sync"
    (100.00/100%)

real    1m23.873s
user    0m0.218s
sys     0m2.114s

(This surprising result is repeatable)

I reproduce this writing to loop device, looks like a bug in qemu-nbd.

Nir