headers
Trond Myklebust | 1 Feb 2005 01:21
Picon
Picon

Re: Minor Versioning.

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?

Cheers,
  Trond

--

-- 
Trond Myklebust <trond.myklebust <at> fys.uio.no>

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 2 comments |
headers
Robert Gordon | 1 Feb 2005 02:25
Picon

Re: 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 <at> ietf.org
(Continue reading)

Permalink | Reply | 1 comment |
headers
Noveck, Dave | 1 Feb 2005 14:54
Picon

RE: Minor Versioning.

> 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
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robert Gordon | 1 Feb 2005 18:22
Picon

Re: Minor Versioning.


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.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trond Myklebust | 1 Feb 2005 19:47
Picon
Picon

Re: Minor Versioning.

må den 31.01.2005 Klokka 19:25 (-0600) skreiv Robert Gordon:

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

The minor version is always known to the client, since it supplies it as
an argument to COMPOUND. The server will return
NFS4ERR_MINOR_VERS_MISMATCH if it does not support that minor version.

Beyond that, NFS4ERR_NOTSUPP is sufficient to ascertain which ops
actually have been implemented. In practice it makes little sense for a
server to advertise a minor version if it does not actually implement
any of the features of that minor version, so we should be able to
assume that the number of unimplemented recommended features will always
be small.

Cheers,
  Trond
--

-- 
Trond Myklebust <trond.myklebust <at> fys.uio.no>

_______________________________________________
nfsv4 mailing list
(Continue reading)

Permalink | Reply | 0 comments |
headers
wurzl, mario | 1 Feb 2005 20:30

RE: Minor Versioning.


> -----Original Message-----
> From: nfsv4-bounces <at> ietf.org [mailto:nfsv4-bounces <at> ietf.org] 
> On Behalf Of Trond Myklebust
> Sent: Tuesday, February 01, 2005 1:47 PM
> To: Robert Gordon
> Cc: nfsv4 <at> ietf.org
> Subject: Re: [nfsv4] Minor Versioning.
> 
> må den 31.01.2005 Klokka 19:25 (-0600) skreiv Robert Gordon:
> 
> > > 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..
> 
> The minor version is always known to the client, since it 
> supplies it as
> an argument to COMPOUND. The server will return
> NFS4ERR_MINOR_VERS_MISMATCH if it does not support that minor version.
> 
> Beyond that, NFS4ERR_NOTSUPP is sufficient to ascertain which ops
> actually have been implemented. In practice it makes little 
> sense for a
(Continue reading)

Permalink | Reply | 588 comments |
headers
Noveck, Dave | 1 Feb 2005 20:58
Picon

RE: Minor Versioning.

> Robert's proposal would allow a server to choose not to implement all the
> features of a minor release.

How does it do that?  

I think that decision has yet to be made, and what facilities you provide
(or don't prvide) to interrogate the level of support doesn't affect that.

Right now, I think the idea is that all the features will be optional and
that does have the consequence that you can implement the minor version 
trivially, which is kind of annoying, but I don't see that it is worse 
than that.

-----Original Message-----
From: wurzl, mario [mailto:wurzl_mario <at> emc.com]
Sent: Tuesday, February 01, 2005 2:30 PM
To: 'Trond Myklebust'; Robert Gordon
Cc: nfsv4 <at> ietf.org
Subject: RE: [nfsv4] Minor Versioning.

> -----Original Message-----
> From: nfsv4-bounces <at> ietf.org [mailto:nfsv4-bounces <at> ietf.org] 
> On Behalf Of Trond Myklebust
> Sent: Tuesday, February 01, 2005 1:47 PM
> To: Robert Gordon
> Cc: nfsv4 <at> ietf.org
> Subject: Re: [nfsv4] Minor Versioning.
> 
> må den 31.01.2005 Klokka 19:25 (-0600) skreiv Robert Gordon:
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Trond Myklebust | 1 Feb 2005 21:28
Picon
Picon

RE: Minor Versioning.

ty den 01.02.2005 Klokka 14:30 (-0500) skreiv wurzl, mario:

> Robert's proposal would allow a server to choose not to implement all the
> features of a minor release.

They can do that anyway: a recommended feature is by definition not
mandatory to implement, and mechanisms already exist to allow clients to
probe for it (minor number + NFS4ERR_NOTSUPP).

Having an operation that allows for batch querying of supported
operations only makes sense if we expect large numbers of features to be
optional to implement (as opposed to just one or two operations).
My impression was that minor versions add recommended features which are
by and large supposed to be "on probation". In other words, they are
expected to be strong candidates for "mandatory to implement" in newer
versions of the protocol, else they will be dropped and/or replaced.

A protocol with large numbers of optional features doesn't make sense
from an interoperability perspective.

Cheers,
  Trond

--

-- 
Trond Myklebust <trond.myklebust <at> fys.uio.no>

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike Eisler | 1 Feb 2005 21:57

RE: Minor Versioning.

For what is worth, many years ago, we had similar discussion about
minor version and asking the server for a detailed description of
what it supported, and the discussion was no less lively or
contentious. I think we came to Trond's conclusion:

 > A protocol with large numbers of optional features doesn't make sense
 > from an interoperability perspective.

_______________________________________________
nfsv4 mailing list
nfsv4 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4
Permalink | Reply | 2 comments |
headers
Robert Gordon | 1 Feb 2005 23:00
Picon

Re: Minor Versioning.


On Feb 1, 2005, at 2:28 PM, Trond Myklebust wrote:

> ty den 01.02.2005 Klokka 14:30 (-0500) skreiv wurzl, mario:
>
>> Robert's proposal would allow a server to choose not to implement all 
>> the
>> features of a minor release.
>
> They can do that anyway: a recommended feature is by definition not
> mandatory to implement, and mechanisms already exist to allow clients 
> to
> probe for it (minor number + NFS4ERR_NOTSUPP).

And a client can continue to use that method if they so choose.

>
> Having an operation that allows for batch querying of supported
> operations only makes sense if we expect large numbers of features to 
> be
> optional to implement (as opposed to just one or two operations).

It seems to make sense to me that with the result of one operation
the client can choose to craft the appropriate compound(s) to suite
the capabilities of the server.

> My impression was that minor versions add recommended features which 
> are
> by and large supposed to be "on probation". In other words, they are
> expected to be strong candidates for "mandatory to implement" in newer
(Continue reading)

Permalink | Reply | 0 comments |

Gmane