[gfs-wg] RNS critique

[Manuel Pereira]

> > As for the ?alias?, this type of junction is really nothing more than 
a
> > ?referral junction?.  After discussing this with the GFS-WG, they feel
> > strongly that ?aliases? should be a basic feature of the service, 
however,
> > agree that aliases (with hardlink ?like? behavior) should be optional.
> 
> It remains to be determined exactly what hardlink-like behavior means.
> There are two aspects of hardlinks that might be considered.  One is
> that they are self-healing when namespace changes would break symbolic
> links.  The other is that they are invisible, in the sense that any of
> several names is an indistinguishable handle for the target object.
> 
> I have no objection to providing self-healing links within a repository
> but I think the indistinguishable behavior would be a problem.  My
> concern is that many of the objects linked to would be directories,
> virtual directories in RNS or leaf referrals that would indicate
> directories in another namespace.  Multiple indistinguishable links
> means that directories would have multiple parents.  Thus paths for
> objects would not be unique, so there would be no distinguished pathname
> for objects in the namespace.  File systems have avoided this situation
> for various reasons, allowing hardlinks only for non-directories.
> 
> Perhaps we should offer a junction with the self-healing property but
> without making them indistinguishable from the primary parent-child
> relationship.

I fully agree, and believe this to be the position of the GFS-WG as well. 
"Aliases" will remain a namespace entry, distinguished from its target 
entry.  The "self-healing" aspect that strives to avoid broken links is 
the motivation here.

Thank you for pointing that out Ted.

Best regards,
Manuel Pereira
===============================
IBM Almaden Research Center
1-408-927-1935  [T/L 457]
mpereira at us.ibm.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/gfs-wg/attachments/20050726/97c715a3/attachment.htm