On Fri, Jan 28, 2022 at 01:30:43PM +0100, Hanna Reitz wrote:
> On 28.01.22 13:18, Richard W.M. Jones wrote:
> >On Fri, Jan 28, 2022 at 12:57:47PM +0100, Hanna Reitz wrote:
> >>On 28.01.22 12:48, Richard W.M. Jones wrote:
> >>>On Fri, Jan 28, 2022 at 12:39:11PM +0100, Hanna Reitz wrote:
> >>>>So I actually don’t know why it works for you. OTOH, I don’t
> >>>>understand why the block size affects you over NBD, because I would
> >>>>have expected qemu to internally auto-align requests when they are
> >>>>not aligned (in bdrv_co_pwritev_part()).
> >>>I checked it again and my hack definitely fixes nbdcopy. But maybe
> >>>that's expected if qemu-nbd is auto-aligning requests? (I'm only
> >>>accessing the block layer through qemu-nbd, not with qemu-io)
> >>It’s not just qemu-io, with your diff[3] I get the same EINVAL over
> >>NBD, too:
> >>
> >>$ ./qemu-img create -f qcow2 test.qcow2 64M
> >>Formatting 'test.qcow2', fmt=qcow2 cluster_size=65536
> >>extended_l2=off compression_type=zlib size=67108864
> >>lazy_refcounts=off refcount_bits=16
> >>
> >>$ ./qemu-nbd --fork --image-opts \
> >>driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=test.qcow2
> >>
> >>$ ./qemu-io -c 'write 0 32k' -f raw nbd://localhost
> >>write failed: Invalid argument
> >Strange - is that error being generated by qemu's nbd client code?
>
> It’s generated by qcow2, namely the exact place I pointed out (as
> [1]). I can see that when I put an fprintf there.
I can't reproduce this behaviour (with qemu @ cfe63e46be0a, the head
of git at time of writing). I wonder if I'm doing something wrong?
++ /home/rjones/d/qemu/build/qemu-img create -f qcow2 output.qcow2 64k
Formatting 'output.qcow2', fmt=qcow2 cluster_size=65536 extended_l2=off
compression_type=zlib size=65536 lazy_refcounts=off refcount_bits=16
++ sleep 1
++ /home/rjones/d/qemu/build/qemu-nbd -t --image-opts
driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=output.qcow2
++ /home/rjones/d/qemu/build/qemu-io -c 'write 0 32k' -f raw nbd://localhost
wrote 32768/32768 bytes at offset 0
32 KiB, 1 ops; 00.02 sec (1.547 MiB/sec and 49.5067 ops/sec)
> >I know I said I didn't care about performance (in this case), but is
> >there in fact a penalty to sending unaligned requests to the qcow2
> >layer? Or perhaps it cannot compress them?
>
> In qcow2, only the whole cluster can be compressed, so writing
> compressed data means having to write the whole cluster. qcow2
> could implement the padding by itself, but we decided to just leave
> the burden of only writing full clusters (with the COMPRESSED write
> flag) on the callers.
I feel like this may be a bug in what qemu-nbd advertises. Currently
it is:
$ qemu-nbd -t --image-opts
driver=compress,file.driver=qcow2,file.file.driver=file,file.file.filename=output.qcow2
&
[2] 2068900
$ nbdinfo nbd://localhost
protocol: newstyle-fixed without TLS
export="":
export-size: 65536 (64K)
uri: nbd://localhost:10809/
contexts:
base:allocation
is_rotational: false
is_read_only: false
can_cache: true
can_df: true
can_fast_zero: true
can_flush: true
can_fua: true
can_multi_conn: false
can_trim: true
can_zero: true
block_size_minimum: 65536 <---
block_size_preferred: 65536
block_size_maximum: 33554432
block_size_preferred is (rightly) set to 64K, as that's what the
compress + qcow2 combination prefers.
But block_size_minimum sounds as if it should be 512 or 1, if qemu-nbd
is able to reassemble smaller than preferred requests, even if they
are suboptimal.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
