[gfs-wg] GGF14 Session Minutes & RNS comments

Andre Merzky andre at merzky.net
Wed Jul 13 09:33:01 CDT 2005


[ 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.  

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.



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
> 
> >> On Fri, 8 Jul 2005 16:52:06 -0700, Manuel Pereira <mpereira at almaden.ibm.com> said:
> 
> >> Hello all,
> 
> >> After further consideration, I have added an RNSTypeFault after all (this
> >> was commented on in the previous note regarding the meeting minutes for
> >> session #1).  I find that it proves to be appropriate for the list
> >> operation, particularly for handling the case when a user attempts to list
> >> an entry that is not a virtual directory (see section 1.3.2.3).  It also
> >> seems to offer appropriate utility for the create operation; in this
> >> context it serves to offer the ability to warn a user when a property is
> >> set that is inconsistent with entry type (see section 1.3.2.1).
> 
> >> https://forge.gridforum.org/projects/gfs-wg/document/RNS-Proposed_Final_Draft-v1.7/en/7
> 
> >> Best regards,
> >> Manuel Pereira
> >> ===============================
> >> IBM Almaden Research Center
> >> 1-408-927-1935  [T/L 457]
> >> mpereira at us.ibm.com



-- 
+-----------------------------------------------------------------+
| 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    |                             |
+-----------------------------------------------------------------+





More information about the gfs-wg mailing list