[gfs-wg] RNS critique
Manuel Pereira
mpereira at almaden.ibm.com
Tue Jul 26 13:16:41 CDT 2005
> > 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
More information about the gfs-wg
mailing list