qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] nbd max request size


From: Eric Blake
Subject: Re: [Qemu-block] nbd max request size
Date: Thu, 27 Oct 2016 09:24:34 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0

On 10/27/2016 07:44 AM, Peter Lieven wrote:
> Hi,
> 
> while talking to a very old NBD server from a recent Qemu Version i
> noticed that the max request size for NBD
> changed from 1MB to 32MB somewhen in the past with commit
> 
> commit 2d8214885942becb8f4371a66d6f8c9a9580108a
> Author: Stefan Hajnoczi <address@hidden>
> Date:   Thu May 2 14:23:08 2013 +0200
> 
>     nbd: support large NBD requests
> 
> Is it possible to detect in the client which NBD server is running and
> adjust the limits accordingly?

Not yet.  There's a proposal to enhance the NBD protocol to allow the
server to advertise its limits (at which point any server/client pair
both new enough to know about the new extension can communicate accurate
limits; and if either side is too old, the other side has to resort to
using only safe assumptions or external knowledge):

https://github.com/NetworkBlockDevice/nbd/blob/extension-info/doc/proto.md

And I even have qemu patches written to implement this extension, but am
not sure they will make qemu 2.8 as soft freeze is so close and I still
have other pending patches that have to clear first.

In the meantime, we DO have this patch in 2.7:

commit 476b923c32ece0e268580776aaf1fab4ab4459a8
Author: Eric Blake <address@hidden>
Date:   Thu Jun 23 16:37:08 2016 -0600

    nbd: Allow larger requests

    The NBD layer was breaking up request at a limit of 2040 sectors
    (just under 1M) to cater to old qemu-nbd. But the server limit
    was raised to 32M in commit 2d8214885 to match the kernel, more
    than three years ago; and the upstream NBD Protocol is proposing
    documentation that without any explicit communication to state
    otherwise, a client should be able to safely assume that a 32M
    transaction will work.  It is time to rely on the larger sizing,
    and any downstream distro that cares about maximum
    interoperability to older qemu-nbd servers can just tweak the
    value of #define NBD_MAX_SECTORS.

    Signed-off-by: Eric Blake <address@hidden>
    Reviewed-by: Kevin Wolf <address@hidden>
    Acked-by: Paolo Bonzini <address@hidden>
    Cc: address@hidden
    Reviewed-by: Fam Zheng <address@hidden>
    Reviewed-by: Stefan Hajnoczi <address@hidden>
    Signed-off-by: Kevin Wolf <address@hidden>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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