Re: [nfsv4] Minor Versioning.

Next message: wurzl, mario: "RE: [nfsv4] Minor Versioning."
Previous message: Robert Gordon: "Re: [nfsv4] Minor Versioning."
In reply to: Robert Gordon: "Re: [nfsv4] Minor Versioning."
Next in thread: Noveck, Dave: "RE: [nfsv4] Minor Versioning."

trond.myklebust@fys.uio.no

Subject: Re: [nfsv4] Minor Versioning.
From: Trond Myklebust <trond.myklebust@fys.uio.no>
Date: Tue, 01 Feb 2005 10:47:26 -0800
Message-Id: <1107283646.10493.74.camel@lade.trondhjem.org>

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@fys.uio.no>

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