Re: [nfsv4] Last call for NSDB Protocol for Federated Filesystems (Oct 4 - Oct 22nd)

[Robert Thurlow <[e-mail]>]

James Lentini wrote:

> There has been some discussion regarding the fedfsAnnotation LDAP 
> attribute defined in Section 4.2.1.12 that I wanted to record as part 
> of this thread.
> 
> Chuck Lever discovered some ambiguities in the description of this 
> attribute's format. We discussed those issues during the FedFS concall 
> on 10/14. A revised description that attempts to eliminate those 
> ambiguities is included below.

I like the revised text without reservation.

> In the process of reviewing the revised text, Chuck, my co-authors, 
> and I have have been considering the utility of including this 
> annotation mechanism. Before LDAP was chosen for the NSDB protocol, 
> this attribute was created to allow private schema extensions. Given 
> our use of LDAP, this attribute may be obsolete.
> 
> Using LDAP there are other, arguably more natural, ways to allow for 
> schema extensions. For example, LDAP allows an entry's schema 
> definition to be extended by adding additional object types to the 
> entry. In this approach, the KEYs and VALUEs defined in Section 
> 4.2.1.12 map to LDAP attribute types and values respectively. This 
> approach would allow implementers to define their own annotation 
> attributes, and would allow for standardizing such attributes if there 
> was interest.
> 
> Are there objections to removing the fedfsAnnotation attribute from 
> the schema and recommending that schema extensions be handled as 
> described above?

I wish to create a management application which uses the
annotations fields as described in the current NSDB schema,
and I think the use case really requires the current form
of the specification, and not schema extensions.

The interesting-to-me use case is a kind of a back pointer -
a way to track back from an FSL and/or FSN to the place in
the namespace where this item is referenced.  I don't think
this can every be truly reliable, but if you're taking a
disk array down for planned maintenance and can send an
outage warning saying that "the following filesystem paths
are known to be affected", that could be useful at times.
The unreliability is why this is not something I have tried
to make a core part of the NSDB protocol.

So the goal is something like a "mountpath=/nfs4/my/path"
piece of data.  The NSDB protocol as currently specified
will let me just write this attribute whenever I manage a
junction.

If I need to do this with LDAP schema extensions, someone
must go through the non-standard LDAP management interface
to get these bits added to the schema before I do my first
bit of work in my management application.  That might be me,
the vendor, trying to script something for all known LDAP
implementations, or it might be my customer trying to read
the fine manuals and do what I conceptually guide him to do.
How many of us would ever do that as a vendor or a customer?
Even if my environment is homogeneous, I may have to touch
every LDAP server I use for FedFS, depending on what any
replication solution supports.

In summary, I think I have something I would really like to
implement which cannot be done properly without annotations
as currently specified, so I would like them kept.

Rob T