[gfs-wg] GGF14 Session Minutes & RNS comments

Craig Everhart craigev at us.ibm.com
Wed Jul 13 10:38:01 CDT 2005





Andre Merzky wrote on 07/13/2005 10:33:01 AM:

> [ Disclaimer: Since I only loosely follow the mails on this
>   list, I might be on the wrong track with my reply below.
>   Please ignore the post then :-) ]
>
> What Osamu describes seems very useful.  However, to me it
> is a behaviour that I, as a user, would not expect.  If
> compared to a file system: if I move a symbolic link or
> alias target, or rename some elements of the target path,
> the link or alias brakes.

Actually, isn't there a bug in Osamu's example?  It clouds the
issue, for me at least.  In his example, I'd get a TargetPath
of ../c for the alias junction.  If you had an example like

           a
          / \
         x   y
        /     \
       b       c

In this case, with the same role for a, b, and c, b's
TargetPath would be "../../y/c", right?  So I'm assuming
that what we're discussing is whether a rename of the
name "y" to "yy" changes the TargetPath to ../../yy/c or not.
Or for that matter whether renaming c to cc changes it
to ../../y/cc or not.

> If you want to avoid that, as described by Osamu, I would
> see problems in scalability, since renaming a root of a
> large tree would require to 'heal' a large number of
> links/aliases (think race conditions...).
>
> Cheers, Andre.

Right, so if the different possible types for y and c affect
the answer, the effects should be spelled out, because it
constrains the possible ways that the name space is represented
in data structures.  As Andre mentions, there's at least
one well-known representation that doesn't match what Osamu
suggests.

            Regards,
            Craig

> Quoting [Osamu Tatebe] (Jul 13 2005):
> > Date: Wed, 13 Jul 2005 11:40:09 +0900 (JST)
> > To: gfs-wg at ggf.org
> > Subject: Re: [gfs-wg] GGF14 Session Minutes & RNS comments
> > From: Osamu Tatebe <o.tatebe at aist.go.jp>
> >
> > Thanks for the revised document.
> >
> > Regarding alias junction, 'TargePath' may be changed when one of
> > parent directories is moved or renamed even if 'AliasCount' of the
> > moved directory is zero since 'TargetPath' is a pathname to the
> > target.
> >
> > For example, here is a directory tree;
> >
> >                 a
> >                / \
> >               b   c
> >
> > b is an alias junction that points to c.  In this case, TargetPath of
> > b is '../a/c'.  When a is moved to aa, the TargetPath should be
> > changed to '../aa/c' even if AliasCount of aa is zero.
> >
> > This is actually a side effect when we change TargetPath from OID to
> > pathname.  I think this is the last major issue.
> >
> > Let's have a conference call next week.  Arun, can you set up this?
> >
> > Thanks,
> > Osamu
....
>
>
> --
> +-----------------------------------------------------------------+
> | Andre Merzky                      | phon: +31 - 20 - 598 - 7759 |
> | Vrije Universiteit Amsterdam (VU) | fax : +31 - 20 - 598 - 7653 |
> | Dept. of Computer Science         | mail: merzky at cs.vu.nl       |
> | De Boelelaan 1083a                | www:  http://www.merzky.net |
> | 1081 HV Amsterdam, Netherlands    |                             |
> +-----------------------------------------------------------------+

Craig Everhart
+1 919 543 2169
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/gfs-wg/attachments/20050713/88cd2ec1/attachment.htm 


More information about the gfs-wg mailing list