[Federated-fs] Glitch in the new schema -- possible workarounds

[Ellard, Daniel]

As I was implementing the additions to the schema that we discussed
yesterday, I ran into a small but nasty glitch that makes doing it the
"easy" way fail.  The problem is when we have a fileset with multiple
junctions to the same fileset.

This is best illustrated with an example: say we allow "aliases" in the
namespace, i.e., 

	/fedfs/home/ellard

And

	/fedfs/home/daniel.ellard

Are both junctions from the fileset that contains /fedfs/home to my home
directory.  (the way netapp has its internal apps configured, I'm ellard
sometimes and daniel.ellard other times, so this might actually be
helpful...)

So let's say that we've updated the NSDB to contain a record saying that
my home directory fileset is a child of the /fedfs/home/ fileset.  Now
imagine that I want to delete /fedfs/home/daniel.ellard -- what happens
to the record?  If there's only one record that one of these is a child
of another, then now we've lost the "ellard" info as well.

One solution would be to have a reference count for each child FSN, and
not delete the record unless the reference count goes to zero.  This has
the least impact on the server, but has a tragic flaw -- I don't know
how to do it LDAP, because the incrementing/decrementing really has to
be made atomic.  Does anyone know how to do this?

A second solution would be to require that the server provide some
disambiguating info along with each junction (perhaps the inode +
generation number).  This needs to be something that the server (and
admin) can recreate whenever it wants to mention the junction to the
NSDB, but we want it to have a low overhead for the server -- minimal
new plumbing, minimal runtime impact.  Suggestions welcome.

-Dan