Subject: Re: [nfsv4] FedFS: Question regarding fedfsNfsMajorVer and fedfsNfsMinorVer

From: "Haynes, Tom" <[email-masked]>
Date: Fri, 15 Jun 2012 22:42:35 +0000

Did you guys ever reach consensus on this question off list?

I.e., what impact is there to the draft-ietf-nfsv4-federated-fs-protocol proposal?

On Oct 25, 2011, at 2:55 PM, Daniel Ellard wrote:

> The original thought was that this was info that only the client would
> care about; the client would look through the fsls returned until it
> found an fsl that had a version of NFS that the client supported (or
> preferred).
> 
> You raise an interesting point, however; if the server exports the fs
> via more than one protocol, the client has no way to specify which one
> they want.  Do we want there to be such a mechanism, or is it enough
> that the server knows that the client wouldn't have selected the fsl
> for a server that exported the fs using a protocol that the client
> couldn't handle?
> 
> -Dan
> 
> On Tue, Oct 25, 2011 at 2:09 PM, Chuck Lever <[email-masked]> wrote:
>> Hi-
>> 
>> Building a bit on the FedFS + NFS fs_locations thread from last week...
>> 
>> How is the content of the fedfsNfsMajorVer and fedfsNfsMinorVer attributes communicated to NFS clients?  There is no field in fs_locations_info4 that corresponds to these attributes.
>> 
>> I've glanced through the NSDB protocol draft, but don't see any explanation for how this data, stored in required attributes, is made available to clients.
>> 
>> --
>> Chuck Lever
>> chuck[dot]lever[at]oracle[dot]com
>> 
>> 
>> 
>> 
>> _______________________________________________
>> nfsv4 mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/nfsv4
>> 
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4

---

From: Chuck Lever <[email-masked]>
Date: Fri, 15 Jun 2012 18:56:04 -0400

Hi-

> Did you guys ever reach consensus on this question off list?

Not that I recall.

> I.e., what impact is there to the draft-ietf-nfsv4-federated-fs-protocol proposal?

I think at the very least the draft needs to provide some guidance about how a server uses those fields.  It's late on a Friday, so what say I post some sample text next week, and we can go from there?

---

From: Chuck Lever <[email-masked]>
Date: Fri, 22 Jun 2012 15:21:45 -0400

> I think at the very least the draft needs to provide some guidance about how a server uses those fields.  It's late on a Friday, so what say I post some sample text next week, and we can go from th…

Section 4.2.1.15 has this language, which describes the FedFsNfsMajorVer attribute:

 For example if the FSL was exported via NFS 4.1, the contents of this attribute would be the value 4.

Similar language exists in section 4.2.1.16 for the FedFsNfsMinorVer attribute.  These sections describe what these attributes contain, but no text discusses how these values can be used.

One author of this draft reports that these values are intended for clients:

> The original thought was that this was info that only the client would care about; the client would look through the fsls returned until it found an fsl that had a version of NFS that the client supported (or preferred).
> 
> You raise an interesting point, however; if the server exports the fs via more than one protocol, the client has no way to specify which one they want.  Do we want there to be such a mechanism, or is it enough that the server knows that the client wouldn't have selected the fsl for a server that exported the fs using a protocol that the client couldn't handle?

The mechanism of NFS referral does not have the ability to pass NFS protocol version information to clients.  A client can request either GETATTR(fs_locations) (NFSv4.0 or NFSv4.1) or GETATTR(fs_locations_info) (NFSv4.1 only) to obtain a list of file set locations, but neither reply structure contains a field for NFS major or minor version.  Thus clients cannot choose among FSLs based on the values in these FSL attributes, as was the original intention.

Therefore, it is up to the server to use the FedFsNfsMajorVer or FedFsNfsMinorVer attributes.  The relevant discussion is in section 2.8.3.  Here are some possible alternatives:

	• The server can ignore these values.  It would attempt to return all FSL records for an FSN to a client during a referral event, whether the client asked for fs_locations4 or fs_locations_info4.  The attributes in FSL records that correspond to fields not included in an fs_locations reply would be ignored, as recommended in section 2.8.3; MinorVer 0 FSL attributes SHOULD contain the default values shown in the table in section 5.1.3.2. If this is the intention, the MajorVer and MinorVer attributes are useless, and we should consider removing them.

	• The server can filter the FSLs based on the request a client uses to access the server.  If a client uses GETATTR(fs_locations), the server would construct an fs_locations response with only FSL records whose MajorVer is 4 and whose MinorVer is 0.  The attributes in FSL records that correspond to fields not included in an fs_locations reply would be ignored; MinorVer 0 FSL attributes SHOULD contain the default values shown in the table in section 5.1.3.2.  This would require two FSL records for each location, which is cumbersome, and probably needless in the face of 2.8.3.

Section 2.8.3 describes how to code a single FSL for each physical location such that the information contained in the FSL can be used to construct either an fs_locations or an fs_locations_info reply.  Perhaps this section could also propose good practice for clients presented with a multitude of locations records.  Perhaps all that is required here is a citation of the section in 5661 that covers this topic; that would be RFC 5661 section 11.9 for fs_locations and section 11.10 for fs_locations_info ?

---

From: Robert Thurlow <[email-masked]>
Date: Fri, 22 Jun 2012 13:37:51 -0600

> 	• The server can filter the FSLs based on the request a client uses to access the server.  If a client uses GETATTR(fs_locations), the server would construct an fs_locations response with only FSL…

Since a V4.1 client can request fs_locations, it seems bad to
guess from the request what filtering to do.  It's harder to
get, but the protocol version of the client would work better
if we decide to filter.  Either way, having to store duplicate
FSLs seems a PITA.

I would rather drop these fields, since they can't be sent to
the client, where they would be useful.  The client can find
out what versions are supported with extra work.

Rob T