Re: [nfsv4] NFSv4.2 draft inter server copy correction

[Chuck Lever <[e-mail]>]

On Mar 3, 2015, at 4:34 PM, Tom Haynes <[e-mail]> wrote:

> 
>> On Mar 3, 2015, at 11:20 AM, Chuck Lever <[e-mail]> wrote:
>> 
>> 
>> On Mar 3, 2015, at 2:11 PM, Tom Haynes <[e-mail]> wrote:
>> 
>>> 
>>> Look at the available URLs:
>>> 
>>>      nfs://203.0.113.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/
>>>      _FH/0x12345
>>> 
>>>      nfs://192.0.2.18//_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/
>>>      0x12345
>> 
>> NFS URIs are defined in the FedFS NSDB protocol doc. Do these
>> URLs conform to that specification, or does NFSv4.2 construct
>> NFS URLs differently?
> 
> These are not NFS URLs, they are COPY URLs.

In other words, the “nfs” scheme name means something different when
used to mount a public NFS server or store a FileSet Location than it
does when used in a COPY URL?

Section 3.1 of RFC 3986 says:
 
   Each URI begins with a scheme name that refers to a specification for
   assigning identifiers within that scheme.  As such, the URI syntax is
   a federated and extensible naming system wherein each scheme’s
   specification may further restrict the syntax and semantics of
   identifiers using that scheme.

The specification for the path component of an nfs:// URI is in
section 2.8.1.2 of the FedFS NSDB protocol draft. The meaning of the
particular URI that you pass in your examples is a file whose path
name is:

  /_COPY/FvhH1OKbu8VrxvV1erdjvR7N/203.0.113.56/_FH/0x12345

and is accessed via NFSv4.

I may be wrong about this, but I don’t think you can change the
interpretation of well-known URI schemes. Does anyone here know
for sure?

You _can_ create new URI schemes and specify their naming system in
the minor version 2 draft. That might be a cleaner approach to
accessing the source server’s FH space.

>> See
>> 
>> https://datatracker.ietf.org/doc/draft-ietf-nfsv4-federated-fs-protocol/?include_text=1
>> 
>> Section 2.8.1.
>> 
> 

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