Re: [nfsv4] [FedFS] Root fileset questions

[<[e-mail]>]

There I go reading too much into SHOULD's rather than MUST's again.  Sorry about that.

I look forward to discussing further whenever we have time (today or future).

Thanks
Chris

-----Original Message-----
From: James Lentini [mailto:[e-mail]] 
Sent: Friday, 11 December 2009 5:23 a.m.
To: Stacey, Chris
Cc: [e-mail]
Subject: Re: [nfsv4] [FedFS] Root fileset questions



On Wed, 9 Dec 2009, [e-mail] wrote:

> 
> Another possible topic for discussion in tomorrow’s FedFS call.

Yes, we can discuss this on the call today as well.

We intentionally separated the standardization of a root fileset for 
the rest of the FedFS protocols. I sent an email to the WG mailing 
list last April describing this plan:

http://www.ietf.org/mail-archive/web/nfsv4/current/msg06981.html

The focus and interest has been on the core FedFS protocols. We've 
informally discussed a root fileset definition, but an official IETF 
proposal has not been made yet.

> We have been talking about using DNS SRV records to locate file servers that
> export the root fileset for a namespace.    But how does a file server
> wanting to export the root of a namespace know what that root fileset
> contains?

A root fileserver may export a normal filesystem (perhaps replicated 
between multiple fileservers) or a root fileserver may export a root 
fileset. In the former case, a root fileset is not necessary.

> R15(b) of the requirements spec
> (http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-reqts-06.txt) says
> that the contents of the root fileset are defined/stored in the NSDB.   

That may be an implication of this requirement.

The exact text is:

         b.  It SHOULD be possible for a fileserver to locate an NSDB
             that stores the layout of a root fileset.

Since the structure of the root fileset has not been defined, there is 
still some flexibility on what the NSDB stores.

> R15(b) also says that it should be possible for the a fileserver to locate
> an NSDB that stores the layout of a root fileset.
> 
> I can’t remember where it is specified but the root fileset can contain only
> directories and junctions.   

This was the consensus in our discussions on the topic. As I 
mentioned, a formal specification of the root fileset has not been 
proposed yet.
 
> R15(g) says that each file server wishing to provide access to the root of a
> namespace must render a representation of the root fileset for the namespace
> by extracting the definition from the NSDB for that namespace.

It is a SHOULD, not a MUST, and then only "If a root fileset is 
defined".

> I have a few questions related to the above…
> 
>  
> 
> (1) How does the file server know which NSDB to query to find out the
> contents of the root fileset for a given namespace?     Doesn’t it need a
> special ‘root junction’ that identifies the authoritative NSDB for the root
> fileset for the namespace?
> 

Again, there isn't a definitive root fileset specification, so it 
could be defined to work in many different ways. 

A special 'root junction' would be one possibility.

Another option would be to use the standard FedFS junction and FSN 
format, but define a special root FSL. Recall that there is already an 
FSL LDAP object hierarchy with a fedfsFsl superclass and a fedfsNfsFsl 
subclass. A 'fedfsRootFsl' could be defined for the root fileset.

I'm sure that there are other options as well.

> 
> (2) Given that a root fileset can contain junctions and directories and it
> is stored in the NSDB, do we not need LDAP objectclass definitions for
> junctions and directories in the NSDB?    Forgive me if I missed them, I
> just expected to find them in section 4.2 of
> http://www.ietf.org/id/draft-ietf-nfsv4-federated-fs-protocol-03bis.txt.
> 

If the root was rendered from an NSDB-based image, then one or more 
LDAP objects would be necessary. Again, if the root is a standard 
filesystem, then no NSDB-based image is necessary.

> 
> Following from #2, it would be helpful to include equivalent  LDAP examples
> for junctions and directories in the NSDB in section 5.1 of the protocol
> specification.
> 

I think examples would make sense in a specification describing the 
root fileset, not in the NSDB specification.

> 
> (3)  R15(d) says that the root fileset definition must be able to be
> replicated between NSDBs.    

This is a SHOULD, not a MUST.

> That, and file server rendering the root
> fileset to clients, leads to the question – how do replica NSDB's and/or
> file servers that want to render the root fileset get updates?    The
> fedfs-rootfileset draft that Renu circulated back in Sep. '08 says that this
> was discussed but no conclusion reached (thanks for digging that out for me
> James).   Seem like we need to come to a conclusion on this.
> 
>  

I agree, this is an area that would need to be well defined in a root 
fileset specification.

> (4) What is the authentication model for access to the contents of the root
> file set?  AUTH_NONE, AUTH_SYS?   I think this is the question that came up
> recently and started me looking into all this.
> 
>  
> 
> (5) What is the security model within the root file set?  Completely open? 
>  Un-modifiable mode bits and ACLs that are open (read-only) to all?
> 
>  

Security is another area that would need to be well defined in a root 
fileset specification. We've discussed this topic in the past, but I 
don't remember coming to any conclusions.