Re: [nfsv4] FedFS: Comment about fedfsFslPort

[Chuck Lever <[e-mail]>]

Hi James-

On Oct 20, 2011, at 7:17 AM, James Lentini wrote:

> 
> 
> On Wed, 19 Oct 2011, Chuck Lever wrote:
> 
>> 
>> 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.  
> 
> Actually a fedfsFslHost can store a DNS name, IPv4 address, or IPv6 
> address.
> 
> The fedfsFslHost attribute's format is defined by its superior 
> attribute's format, the fedfsNetAddr, which "is the locative name of a 
> network service in either IPv4, IPv6, or DNS name notation. See 
> section 4.2.1.2 of draft-ietf-nfsv4-federated-fs-protocol-11 for the 
> full definition.

Got it.

>> 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.
> 
> I don't see any need to do a translation.

Your proposal adds a new translation requirement by specifying the FslPort in a separate field, and requiring that the file server perform a DNS lookup to construct a universal address in order to communicate the port number to clients.  (Understood that this would only be necessary if FslPort contains a port number other than 2049).  The natural way to express server names for NFS, codified in RFC 5661, includes a universal address, and the server name data can be multi-valued.

My quibble is not with the richness of the NFS FSL, but rather that this information is expressed in a particular way in existing NFS implementations, and we are not providing the same way to express it in FedFS.  Is there a strong reason for this?  Are we for instance trying to address some deficiency in the fs_locations_info4 data?

I continue to believe the FSL subclasses, on principal, should reflect the data and types in native file system referral information as closely as possible, and currently the NFS FSL does not.  The file server may _choose_ to implement some dynamic policy with this data, but I don't think it should be limited to that: it should also be allowed to simply copy the information from the NFS FSL and stuff it into the fs_locations_info4 struct, in all cases.  That would be the least surprising/confusing behavior to admins.

I'm willing to concede on the multi-valued server name point, as an FSL is supposed to represent a single location.  Noted, however, that a file server MAY convert multiple FSLs that vary only in their server name field by compressing this FSL list to a single fs_locations_info4 record with a list of server names.  Right?  Are there exceptions?

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

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