Subject: [nfsv4] NFS Pathless Objects

From: <[email-masked]>
Date: Wed, 23 Jun 2010 18:21:29 -0400

Is there a mailing list for the discussion of the NFS Pathless Objects
draft, or is this the appropriate place?

http://tools.ietf.org/id/draft-dipankar-nfsv4-pathless-objects-00.txt

I don't see the need for a PUTOBJROOTFH call.  Currently, PUTROOTFH
provides access to a collection of file systems stitched together in a
pseudo-root.  The top level of an object repository is named (just like
the root of a file system).  Why not simply stitch these object
repositories into the same pseudo-root? Perhaps object repositories are
all at the top of the pseudo-root, or perhaps they appear anywhere in
the hierarchy (their position in the hierarchy may be a useful mechanism
for identifying object repositories).  An attribute of an object
determines whether it is a normal file system directory, and will thus
be accessed via the legacy hierarchical NFS namespace operations, or if
the object is the root of an object repository and therefore access to
the objects below this point are performed via the operations proposed
in this draft.

  -Dan

---

From: Tom Haynes <[email-masked]>
Date: Wed, 23 Jun 2010 23:00:22 -0500

[email-masked] wrote:
> repositories into the same pseudo-root? 

Because they are different name spaces.

What if an Object Set has the same name as a directory in the root of 
the file-system? Which
gets displayed?

Also, while the document does not state whether the new operations are 
Required, Recommended,
or Optional, I would argue that they are Optional. Thus, if a server 
implemented them and stitched
them into the same pseudo-root as the file namespace, then it could 
cause problems for a client
which has not implemented pathless objects.

Keeping them separate avoids many issues.

> Perhaps object repositories are
> _______________________________________________
> nfsv4 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nfsv4
>

---

From: Tom Haynes <[email-masked]>
Date: Wed, 23 Jun 2010 23:12:22 -0500

1) It appears that pathless objects can neither be replicated onto other 
servers nor migrated. That appears to be limiting.

2) I understand the intent here:

   An Object Set is expected to have certain access primitives
   associated with it, which are used by the server to provide access
   control for the objects contained in the Set. The server can
   implement a policy based mechanism to grant specific clients or
   groups of clients access to an Object Set. Such an implementation can
   be analogous to the exports mechanism commonly used with the NFS
   exported directories.  The NFS server MUST keep track of all the
   Object Sets it has.  The server SHOULD make visible all the exported
   Object Sets to the clients, subject to access control policies at the
   server.  This RFC does not pose any other requirements on the
   implementation of an access policy for an Object Set.

But I would strike the second and third sentences. Perhaps something like:

   An Object Set is expected to have certain access primitives
   associated with it, which are used by the server to provide access
   control for the objects contained in the Set. This control can also
   include visibility into the namespace. The NFS server MUST keep track
   of all the Object Sets it has.  The server SHOULD make visible all 
   Object Sets to the clients, subject to access control policies at the
   server.  This RFC does not pose any other requirements on the
   implementation of an access policy for an Object Set.

We've made sure to avoid talking about exports in RFC 3530 and 5661, so 
I'd like to keep on
avoiding mention of it.

An implication of this paragraph is that the server MUST be able to 
provide a pseudo-Object Set
in this name-space. I don't see any discussion of that need in the document.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2010 00:33:07 -0400

> -----Original Message-----
> From: Tom Haynes [mailto:[email-masked]] 
> Sent: Wednesday, June 23, 2010 9:00 PM
> To: Muntz, Daniel
> Cc: [email-masked]
> Subject: Re: [nfsv4] NFS Pathless Objects
> 

That makes sense.  I was reading the part about MUST w.r.t. naming of
the object sets as indicating an "interface" point between a
hierarchical namespace and an object store.  I suppose even the object
sets, at the root level, could have the same search semantics as the
objects within the sets (thus requiring them to be a separate
namespace).

> What if an Object Set has the same name as a directory in the root of 

Same as above.

> Keeping them separate avoids many issues.

True.  It still bothers me that this seems like an additional "export"
but the alternatives that come to mind are not terribly elegant.

---

From: <[email-masked]>
Date: Thu, 24 Jun 2010 00:35:19 -0400

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Tom Haynes
> Sent: Wednesday, June 23, 2010 9:12 PM
> Cc: [email-masked]

Yes, that would be limiting to the point of making them completely
useless.  How did you reach this conclusion?

---

From: Tom Haynes <[email-masked]>
Date: Thu, 24 Jun 2010 18:44:19 -0500

> useless.  How did you reach this conclusion?

No, not completely useless. We get a lot of mileage of out plain NFSv4 
without
either property.

An Object Set could be considered to be equivalent to a filesystem and 
could be
either replicated or migrated.

At first I thought the implication in the draft is that there is just 
one filesystem which has all of the
objects stored on it. But the draft does not mandate that. The server 
returns a NFS filehandle
for the object, which means that it can contain a fsid and root export 
identifier.

Further, if the Object Set namespace has exports, then it must have a 
pseudo-Object Set
capability. However, thinking of them as filesystems seems to be wrong:

   When the client has created an Object Set or has access to an
   existing Object Set within the server, it can create pathless objects
   that are contained in the Object Set. The pathless object, even
   It is not necessary to implement a pathless object as a file.  It can
   be any physical entity, which has a unique identifier in the form of
   a NFS filehandle.  So the filehandle serves as an unique identifier
   for the object and there is no requirement that it SHOULD represent a
   file.  The server is REQUIRED to maintain the linkage between the
   object and it's Set and is free to distribute and store the objects
   in the best possible way to satisfy the needs of the application.
   though it is contained in a Set, can be physically located anywhere.

While having migration and replication would be nice, it doesn't appear 
to be a mandatory
requirement and will complicate the overall design. Of course, if the 
goal is ever to support
fs_locations or fs_locations_info in this namespace, it would be better 
to do so now.