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

Re: [PATCH v2 2/3] doc: Clarify maximum size limits



28.03.2018 19:21, Eric Blake wrote:
On 03/16/2018 11:10 AM, Vladimir Sementsov-Ogievskiy wrote:

-If block size constraints have not been advertised or agreed on externally, -then a client SHOULD assume a default minimum block size of 1, a preferred
-block size of 2^12 (4,096), and a maximum block size of the smaller of
-the export size or 0xffffffff (effectively unlimited).  A server that
-wants to enforce block sizes other than the defaults specified here
-MAY refuse to go into transmission phase with a client that uses
-`NBD_OPT_EXPORT_NAME` (via a hard disconnect) or which fails to use
-`NBD_INFO_BLOCK_SIZE` with `NBD_OPT_GO` (where the server uses
-`NBD_REP_ERR_BLOCK_SIZE_REQD`), although a server SHOULD permit such
-clients if block size constraints are the default or can be agreed on
-externally.  When allowing such clients, the server MUST cleanly error
-commands that fall outside block size constraints without corrupting
-data; even so, this may limit interoperability.
+If block size constraints have not been advertised or agreed on

"advertised" here means answer on OPT_INFO or OPT_GO

Mostly yes.  The information reported by NBD_OPT_INFO may differ from that reported by NBD_OPT_GO if the client did other things in the meantime, or changed its set of requested info; but the spec does state that if the client passes the same request to both, and NBD_OPT_INFO succeeded, then NBD_OPT_GO should also report the same results on success.

Qemu server's implementation is interesting: right now, it wants to always advertise a minimum block size of 512, although I want to eventually relax it to advertise a minimum block size of 1.  So the code does:


    /* Send NBD_INFO_BLOCK_SIZE always, but tweak the minimum size
     * according to whether the client requested it, and according to
     * whether this is OPT_INFO or OPT_GO. */
    /* minimum - 1 for back-compat, or 512 if client is new enough.
     * TODO: consult blk_bs(blk)->bl.request_alignment? */
    sizes[0] =
            (client->opt == NBD_OPT_INFO || blocksize) ? BDRV_SECTOR_SIZE : 1;

but follows up with:

    /* If the client is just asking for NBD_OPT_INFO, but forgot to
     * request block sizes, return an error.
     * TODO: consult blk_bs(blk)->request_align, and only error if it
     * is not 1? */
    if (client->opt == NBD_OPT_INFO && !blocksize) {
        return nbd_negotiate_send_rep_err(client,
NBD_REP_ERR_BLOCK_SIZE_REQD,

so the possible outcomes of an INFO followed by GO are:

INFO with size, GO with size: for now, both report 512 (qemu might be fixed such that both report 1 in cases where alignment doesn't matter); this is compliant, since both replies match

INFO without size, GO with size: info reports 512 but fails with NBD_REP_ERR_BLOCK_SIZE_REQD, GO reports 512 and succeeds; this is compliant whether or not both replies matched, because the INFO response did not succeed

INFO without size, GO without size: info reports 512 but fails with NBD_REP_ERR_BLOCK_SIZE_REQD, GO reports 1 and succeeds; the results differ, but this is compliant because the INFO response did not succeed

INFO with size, GO without size: INFO reports 512, GO reports 1; the results differ, but this is compliant because the client changed the request between the two calls

So I don't think I'll change this text for v3, but I am pointing out that "advertised" strictly means only what NBD_OPT_GO replies, as there are situations where the reply to NBD_OPT_INFO is not final


thank you for enlightening this, I didn't thing that my tiny note will raise such a big question)




[...]


  The maximum block size represents the maximum length that the server
-is willing to handle in one request.  If advertised, it MUST be either
-an integer multiple of the minimum block size or the value 0xffffffff
-for no inherent limit, MUST be at least as large as the smaller of the
-preferred block size or export size, and SHOULD be at least 2^25
-(33,554,432) if the export is that large, but MAY be something other
-than a power of 2.  For convenience, the server MAY advertise a
-maximum block size that is larger than the export size, although in
-that case, the client MUST treat the export size as the effective
-maximum block size (as further constrained by a nonzero offset).
+is willing to handle in one request.  If advertised, it MAY be
+something other than a power of 2, but MUST be either an integer

but, for "something other", only 0xffffffff is possible, so actually the first sub sentence is useless, I think it may be dropped. (to be multiple of the
minimum block size involves to be a power of 2)

No. There are iSCSI devices in the wild that advertise a maximum block size of 15M, which is not a power of 2, but is an integer multiple of the minimum block size (512 or 4k, I'm not sure which).

ahaha, I'm stupid ))) to have integer multiply of power of 2 to be a power of 2 too, this integer should be a power of 2 (don't know, is this sentence understandable in English:)






--
Best regards,
Vladimir


Reply to: