Subject: [nfsv4] The composition of pseudo file systems in single-server namespaces

From: Daniel Ellard <[email-masked]>
Date: Tue, 10 Jul 2007 21:48:31 -0400

This came up today during a discussion of the 4.1 draft, but we didn't have
time to resolve the question and it was suggested that the mailing list
would be a better forum:

Q: What kinds of objects can appear in the pseudo file system used to
implement a single-server namespace?

The example in the draft makes it appear that the only thing that can appear
are directories that are used to stitch together local file systems.  (from
the example, it looks like only a single level of directories is permitted,
so, for example, if we have

    /       - pseudo file system
    /a      - local file system
    /a/b    - could be a pseudo file system
    /a/b/c  - must be a local file system?

The consensus was no, it's OK for the pseudo file system to contain multiple
levels, i.e., a path like /a/b/c/d could have /a/b/c in the pseudo file
system and /a/b/c/d being in a local file system.

The next question is whether anything else can be in the pseudo file system.
Some things that were mentioned:

1. Symlinks (or hard links, although nobody mentioned a use case -- probably
pointless unless ordinary files can be present as well)

2. Ordinary files

3. Referrals

At this point there's really not much pseudo about the file system that
implements the local server namespace, and it can be stitched, via
referrals, directly to other single server namespaces.

The idea of having referrals as first-class objects in the single server
namespace blurs (or erases) the line between the single server namespace and
the multi server namespace, but be able to unify these ideas into a single
abstraction.

If you know what the spec was trying to express here, or have an opinion
about what it should be trying to express, please chime in.

Thanks,
    -Dan

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 10 Jul 2007 22:42:56 -0500

> about what it should be trying to express, please chime in.

As Mike pointed out during the review, the pseudo file system concept
was used in 4.0 to provide a conceptual anchor to a method of namespace
access that differed from NFSv3.  It was also mentioned that the client
doesn't have a method of determine what portion of the namespace  
represents
pseudo file system and what does not.

And, to quote from the spec:

	"A pseudo file system has a unique fsid and behaves
	 like a normal, read only file system."

I think that is sufficient.  If a read only file system has the
potential of containing various object types then the pseudo
file system may as well.  I don't see any need to restrict its
behavior.

Spencer

---

From: "Ellard, Daniel" <[email-masked]>
Date: Wed, 11 Jul 2007 10:57:22 -0400

> -----Original Message-----
> From: Spencer Shepler [mailto:[email-masked]] 
> Sent: Tuesday, July 10, 2007 11:43 PM
> To: Ellard, Daniel
> Cc: [email-masked]
> Subject: Re: [nfsv4] The composition of pseudo file systems 
> in single-server namespaces
> 
> 
> > ...
> > The next question is whether anything else can be in the 
> pseudo file 
> > system.
> > 1. Symlinks (or hard links, although nobody mentioned a use case -- 
> > probably pointless unless ordinary files can be present as well)
> >
> > 2. Ordinary files
> >
> > 3. Referrals
> >
> > At this point there's really not much pseudo about the file system 
> > that implements the local server namespace, and it can be stitched, 
> > via referrals, directly to other single server namespaces.
> >
> > The idea of having referrals as first-class objects in the single 
> > server namespace blurs (or erases) the line between the 
> single server 
> > namespace and the multi server namespace, but be able to 
> unify these 
> > ideas into a single abstraction.
> >
> > If you know what the spec was trying to express here, or have an 
> > opinion about what it should be trying to express, please chime in.
> 
> As Mike pointed out during the review, the pseudo file system 
> concept was used in 4.0 to provide a conceptual anchor to a 
> method of namespace access that differed from NFSv3.  It was 
> also mentioned that the client doesn't have a method of 
> determine what portion of the namespace represents pseudo 
> file system and what does not.
> 
> I think that is sufficient.  If a read only file system has 
> the potential of containing various object types then the 
> pseudo file system may as well.  I don't see any need to 
> restrict its behavior.

Agreed -- from the client's point of view, it should look normal.

But what I want to clarify is whether there's anything required of the
server.  The only thing that is required to satisfy the current examples
is directories and mounts of local file systems.  Do we want to require
any other file system object types, or just leave that up to the
implementators to decide?

-Dan

---

From: Spencer Shepler <[email-masked]>
Date: Wed, 11 Jul 2007 10:03:30 -0500

> implementators to decide?

Implementation choice.

Spencer