qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: "Richard W.M. Jones" <rjones@redhat.com>
Cc: kwolf@redhat.com, qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Hanna Reitz <hreitz@redhat.com>,
	andrey.shinkevich@virtuozzo.com, libguestfs@redhat.com
Subject: Re: Block alignment of qcow2 compress driver
Date: Fri, 28 Jan 2022 15:40:14 -0600	[thread overview]
Message-ID: <20220128214014.6kek62rhvaha3sm7@redhat.com> (raw)
In-Reply-To: <20220128115619.GR1127@redhat.com>

Adding libnbd list (libguestfs) in cc

On Fri, Jan 28, 2022 at 11:56:19AM +0000, Richard W.M. Jones wrote:
> 
> I hacked nbdcopy to ignore block alignment (the error actually comes
> from libnbd refusing to send the unaligned request, not from
> qemu-nbd), and indeed qemu-nbd accepts the unaligned request without
> complaint.

And only after I already replied to your other email, did I then see
your followup recommending to read this one instead ;)

The NBD spec says the client is non-complying when sending under-sized
requests.  If the server accepts it anyway (presumably with RMW
performance pessimizations, as qemu-nbd does), that's a QoI bonus.

> 
> Eric - maybe having some flag for nbdcopy to ignore unaligned requests
> when we know the server doesn't care (qemu-nbd) would work?

Yeah, that might make sense - a command-line option for stating "I
know the server has a nice QoI feature, and I don't mind the
performance pessimization".

Another thing to consider: the way the NBD spec is written, the rules
about a client sending unaligned requests being non-compliant only
applies to a client that requested block size information in the first
place.  If the client did not request block alignment information, the
server should honor anything at alignment of 512 or above (even if it
would prefer a larger minimum); performance may suffer, but this is
needed to cater to older clients that don't know how to request
alignments - and what's more, qemu-nbd specifically has code that
changes what it advertises if the client did not query (that is, an
advertisement of 64k is ONLY possible if the client requested
alignment details).

So maybe the question becomes whether libnbd needs a knob on whether
to request alignment information.  Libnbd commit 9e9c74755 (libnbd
v1.3.10) is where I added the code to unconditionally query for
alignment info.  Given that we now know of a case where NOT querying
causes qemu-nbd to behave differently in what it advertises, adding
such a knob to the API makes total sense, at which point, 'nbdcopy
--ignore-align' becomes a way to request that the client not request
alignment in the first place, rather than as a way to call
nbd_set_strict_mode() to turn off alignment checking.

Looks like I have some API work do propose in libnbd...

> 
> Rich.
> 
> --- a/copy/nbd-ops.c
> +++ b/copy/nbd-ops.c
> @@ -59,6 +59,10 @@ open_one_nbd_handle (struct rw_nbd *rwn)
>      exit (EXIT_FAILURE);
>    }
>  
> +  uint32_t sm = nbd_get_strict_mode (nbd);
> +  sm &= ~LIBNBD_STRICT_ALIGN;
> +  nbd_set_strict_mode (nbd, sm);
> +
>    nbd_set_debug (nbd, verbose);
>  
>    if (extents && rwn->d == READING &&
> 

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org



  reply	other threads:[~2022-01-28 21:42 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-28 11:07 Block alignment of qcow2 compress driver Richard W.M. Jones
2022-01-28 11:39 ` Hanna Reitz
2022-01-28 11:48   ` Richard W.M. Jones
2022-01-28 11:57     ` Hanna Reitz
2022-01-28 12:18       ` Richard W.M. Jones
2022-01-28 12:30         ` Hanna Reitz
2022-01-28 13:19           ` Kevin Wolf
2022-01-28 13:36             ` Richard W.M. Jones
2022-01-28 13:30           ` Richard W.M. Jones
2022-01-28 13:37             ` Richard W.M. Jones
2022-01-28 21:22             ` Eric Blake
2022-01-28 11:56   ` Richard W.M. Jones
2022-01-28 21:40     ` Eric Blake [this message]
2022-02-01 14:13 ` Vladimir Sementsov-Ogievskiy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220128214014.6kek62rhvaha3sm7@redhat.com \
    --to=eblake@redhat.com \
    --cc=andrey.shinkevich@virtuozzo.com \
    --cc=hreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=libguestfs@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=rjones@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).