Subject: Re: [nfsv4] I-D Action: draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt

From: Robert Thurlow <[email-masked]>
Date: Tue, 01 Nov 2011 20:57:25 -0600

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network File System Version 4 Working Group of the IETF.
> 	Filename        : draft-ietf-nfsv4-federated-fs-dns-srv-namespace-10.txt

Hi all,

I am implementing this on a server which has made a well-reasoned design
choice to implement a read-only root filesystem.  The server is a clustered
system with shared storage but independent root filesystems.  This language
in section 3 brings some pain here:

    In order to allow the NFSv4 servers so given to export a variety of
    filesystems, those file servers MUST export the given domain's root
    filesystems at "/.domainroot-{Name}" within their pseudo-filesystems,
    where the "{Name}" is the name of the organization as used in the SRV
    RR.

Clearly, this directory would normally be a subdirectory of the server's
actual root filesystem, which also corresponds to our pseudo-root.  It is
possible to make careful changes to our root filesystems, and it is also
possible to special-case these paths in the NFS server pseudo-root, but
both are unpalatable.

I do not remember substantive discussion on why we chose the current
convention, and it does not seem as important what we use for a convention
as that we state one.  Hence, I would like to change the convention to put
the actual shared root on the server one level further down.  An obvious
choice would be to use "/.domainroot/{Name}" instead, making /.domainroot
a fixed point on which a read-write filesystem could be mounted.

I believe all extant client implementations will need a tweak to accomodate
the SRV record syntax change, and this has passed the sniff test with one
other server implementor.  The change would affect five lines of the spec,
as follows:

<    filesystems at "/.domainroot-{Name}" within their pseudo-filesystems,
---
 >    filesystems at "/.domainroot/{Name}" within their pseudo-filesystems,
286c286
<    "/.domainroot-example.net" in their pseudo-filesystems, which clients
---
 >    "/.domainroot/example.net" in their pseudo-filesystems, which clients
350c350
<    "/.domainroot-{Name}" string.  Thus, the servers listed as targets
---
 >    "/.domainroot/{Name}" string.  Thus, the servers listed as targets
352c352
<    organization's published filesystem as the directory "/.domainroot-
---
 >    organization's published filesystem as the directory "/.domainroot/
355c355
<    directory "/.domainroot-example.net" would be used.
---
 >    directory "/.domainroot/example.net" would be used.

Rob T

---

From: "Everhart, Craig" <[email-masked]>
Date: Wed, 2 Nov 2011 10:22:22 -0400

I don't have any objections to the proposed approach.

What was wanted was that the mounted name be distinct for each domain
name being serviced, so that multiple organizational roots could be
housed on the same NFS server.  This still honors that requirement.

I'll make these changes in the draft unless there's contrary opinion.

		Craig

> -----Original Message-----
> From: Robert Thurlow [mailto:[email-masked]]
> Sent: Tuesday, November 01, 2011 10:57 PM
> Cc: [email-masked]
> Subject: Re: [nfsv4] I-D Action:draft-ietf-nfsv4-federated-fs-dns-srv-
> namespace-10.txt
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Network File System
> Version 4 Working Group of the IETF.
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4