RE: [nfsv4] Minor Versioning.

Dave.Noveck@netapp.com

Subject: RE: [nfsv4] Minor Versioning.
Date: Tue, 1 Feb 2005 08:54:50 -0500
Message-ID: <C98692FD98048C41885E0B0FACD9DFB840D2EE@exnane01.hq.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>

> 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.

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
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.

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.  

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.

   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.

   For each minor version a variable-length bit mask is returned
   with indicates what optional features within that minor version
   are supported by the server.  For a versions not supported by
   the server, a zero-length bit array is returned.

   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.

-----Original Message-----
From: Robert Gordon [mailto:Robert.Gordon@Sun.COM]
Sent: Monday, January 31, 2005 8:25 PM
To: nfsv4@ietf.org
Subject: Re: [nfsv4] Minor Versioning.

On Jan 31, 2005, at 6:21 PM, Trond Myklebust wrote:

> må den 31.01.2005 Klokka 17:22 (-0600) skreiv Robert Gordon:
>> I've been pondering the following :-
>> 	 a server may advertise support for a minor version but may not
>> 	(if the feature is classified as recommended) actually implement
>> 	one (or any) of the 'minor version' features.
>>
>> It has occurred to me that in 4.1 we should recommend a mechanism to
>> query the server of it's capabilities and then make that mechanism
>> mandatory in 4.2; This way it should be easy for a client to figure
>> out if a server can handle sessions, pnfs etc...
>
> Why is the existing NFS4ERR_NOTSUPP insufficient for these purposes?

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.

I don't see how one could achieve the same with NFS4ERR_NOTSUPP,
maybe i'm missing something..

--
Robert.. 

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

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