Re: [nfsv4] Minor Versioning.

Robert.Gordon@Sun.COM

Date: Tue, 01 Feb 2005 11:22:07 -0600
From: Robert Gordon <Robert.Gordon@Sun.COM>
Subject: Re: [nfsv4] Minor Versioning.
Message-id: <6c29c1ca99d334c812f46ffe7a4ee63a@sun.com>

comments inline..

On Feb 1, 2005, at 7:54 AM, Noveck, Dave wrote:

>> The proposal allows for a succinct up-front mechanism to ascertain
>> the operations supported by the server in one round-trip. One could
>> also figure out the minor versions supported by the server if the
>> supported operations in the reply was zero.
>
> It is not a requirement that a minor version add new operations,
> although I suppose almost all will.  You can add new attributes,
> flag bits to existing ops, etc.

Good point.

>
> Even if you assume that all minor versions have at least one added
> new op, it doesn't follow that every client that supports that
> version will support at least one new op.
>
>> I don't see how one could achieve the same with NFS4ERR_NOTSUPP,
>> maybe i'm missing something..
>
> If you mean in one round-trip, then no it can't.  However, if you
> allow multiple round-trips, then clearly the information about what
> set of new ops the server, can be gathered by testing as Trond
> suggests, but it doesn't mean that we know what optional features
> the client supports as these may not map one-to-one to ops.
>
> Also, before you do that, you need to find out what minor versions
> the client supports.  You could do this by trying them and seeing
> if you got NFSERR_MINOR_VERS_MISMATCH.
>
> At some point, this kind of thing gets unacceptably onerous.  It's

Right, just thinking about it was onerous :)

> not clear that v4.1 is that point, but RFC 3530 does reserve op
> code 2 as "reserved for future definition and use with minor
> versioning" so I think that it makes sense to define a scheme for
> it that we think would work for v4.1 and future minor revisions.
> The text of section 14.2 is written assuming that the first minor
> version will define this op.

Ugh!.. (note to self. read the entire RFC)

>
> BTW, page 138 of the spec (first full paragraph) is very specific
> about error codes and in particular that a version 0 client is
> supposed to return OP_ILLEGAL rather than NOTSUPP.  I know my
> server currently treats this incorrectly, and I'm guessing I'm
> not the only one.

I will check/enhance our server.

>
> Anyway, here's my stab at defining op code 2:
>
> 14.2.1.  Operation 2: VERSION_INFO - Get minor version info
>
>    SYNOPSIS
>
>      versionmask -> version_info, feature_info
>
>    ARGUMENT
>
>
>
>      struct VERSION_INFOargs {
>              bitmap4        versions;
>      };
>
>    RESULT
>
>      struct VERSION_INFOresok {
>              bitmap4         versions_supported;
>              bitmap4         feature_info<>;
>      };
>
>      union VERSION_INFOres switch (nfsstat4 status) {
>       case NFS4_OK:
>               VERSION_INFOresok   resok4;
>       default:
>               void;
>      };
>
>    DESCRIPTION
>
>    VERSION_INFO is used by a client to determine which minor versions
>    a server supports and for each of those minor versions, which
>    optional features from that minor version are supported.
>
>    The minor versions that the client supports are encoded as a
>    variable-length bit array with the least significant bit of
>    the first word denoting version zero and proceeding to more
>    significant bits until the first word is exhausted and then
>    proceeding to subsequent words in turn.  Even though it is
>    highly unlikely that more than one word will ever be required,
>    this scheme does allow expansion beyond 32 minor versions.

Are you suggesting that the arguments for OP_VERSION_INFO convey
to the server the client supported versions ? (if so, then the first
paragraph should explicitly state that) -- I was viewing it as a
query, rather than a declaration (i have no preference either way).

>    The server responds with the set of versions that it supports
>    (i.e. those versions for which it will not return the error
>    NFS4ERR_MONOR_VERS_MISMATCH), encoded in the same fashion.
typo: NFS4ERR_MINOR_VERS_MISMATCH

>
>    For each minor version a variable-length bit mask is returned
>    with indicates what optional features within that minor version
typo: which indicates

>    are supported by the server.  For a versions not supported by
>    the server, a zero-length bit array is returned.

It seems like for versions not supported by the server the server should
not turn on the corresponding bit in "versions_supported".

Just for clarity; on getting the reply the client will scan the
versions_supported bit array (lsb -> msb) , and for each bit on
the corresponding feature_info[x] will denote the supported
features.

>
>    Definition of the feature bits for version 0 is as follows:
>
>    TBD
>
>    Definition of the feature bits for version 1 is as follows:
>
>    TBD
>
>    Definition of feature bits for future minor versions will be
>    provided in the RFC defining that minor version.
>

--
Robert..

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4