Re: [nfsv4] FedFS: Comment about fedfsFslPort

[Chuck Lever <[e-mail]>]

On Oct 19, 2011, at 12:10 PM, Chuck Lever wrote:

> 
> On Oct 19, 2011, at 11:54 AM, James Lentini wrote:
> 
>> 
>> 
>> On Wed, 12 Oct 2011, Robert Thurlow wrote:
>> 
>>> Chuck Lever wrote:
>>> 
>>>> Thus there's no need for a separate FSL field to express a port value for
>>>> NFS referrals.  Regardless of whether 3530bis is changed as proposed, I
>>>> think we should remove the fedfsFslPort field, and leave that detail to the
>>>> subclasses of fedfsFsl where it is meaningful.
>>> 
>>> Agreed.
>> 
>> Removing the optional fedfsFslPort attribute from the fedfsFsl 
>> objectclass makes sense to me. Subclasses of fedfsFsl should include a 
>> port when necessary.
>> 
>> However, I believe that an NFS FSL should include a port attribute.
>> 
>> As defined in RFC 5661, NFSv4.1 allows for modified universal 
>> addresses to be included in a referral (see RFC 5661's definition of 
>> the fls_server field in Section 11.10.1).
>> 
>> As defined in Section 4.2.1.2 of 
>> draft-ietf-nfsv4-federated-fs-protocol-11, the format of the 
>> fedfsFslHost attribute does not allow universal addresses or port 
>> values to be specified.
>> 
>> The combination of a fedfsFslHost and fedfsFslPort (renamed to be a 
>> fedfsNfsFslPort?) provide enough information to generate the modified 
>> universal addresses used in NFSv4.1 referrals.
> 
> My concern about this is that now the file server would have to perform a DNS lookup to discover the address that is bound to the fedfsFslHost.  Can we guarantee that the client would get the same results from a DNS lookup, given that hostname?  Does that matter?

I'll go a little further here, based on recent implementation experience.

The intent as I understand it is that an NFS FSL stores information that the file server translates to either fs_locations4 or fs_locations_info4.  The challenge of this translation has been dealing with information in an NFS FSL that is stored differently or is semantically different than what's in fs_locations{_info}4.

This includes not just fedfsFslPort.  fs_locations4, for instance has the possibility of transmitting a list of servernames that share the same export path.  The NFS FSL, however, stores a single server name and a single export path.

And before you mentioned it today, I didn't realize that fedfsFslHost could express only a DNS hostname, and not IP or universal addresses.  /me slaps forehead.  This is another translation complication for file server implementors.  IMO we would be better off if NFS FSLs were a closer match to fs_locations{_info}4.

As an example, we could also move fedfsFslHost to the NFS FSL, and allow the NFS version of this attribute to be multi-valued and contain the full range of string values that are allowed in the fls_server field in fs_locations_info4.  I think that would be more natural for administrators who have already set up NFS referrals using other administrative interfaces native to their platform.

More generally, I don't think we should assume that the data in "FslHost" will be the same type for every network file system, and that this information, therefore, is also specific to subclasses of fedfsFsl.

Thoughts?

--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com