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

[Renu Tewari]

So if I understand it correctly you are deleting the junction and not the
fileset?  So all we need is that the junction tuple <parent_fsn,
target_fsn>  wither by the opaque handle returned by the fileserver
<parent_fsn, target_fsn, opaque_handle1>  This handle could be simply the
filehandle.
or by creating a uniquifier say junction_uuid  so the tuple is
<parent_fsn, target_fsn, junction_uuid>.

regards
renu




                                                                           
             "Ellard, Daniel"                                              
             <Daniel.Ellard at ne                                             
             tapp.com>                                                  To 
             Sent by:                  <federated-fs at sdsc.edu>             
             federated-fs-boun                                          cc 
             ces at sdsc.edu                                                  
                                                                   Subject 
                                       [Federated-fs] Glitch in the new    
             06/13/2008 07:34          schema -- possible workarounds      
             AM                                                            
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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