[Federated-fs] FSN and filesets

[Raj, Theresa]

In this example the FSLs are serverX:/x and serverY:/y, right. So the
pathnames in these FSLs don't include any intermediate junction
components. If there is any junction component in the pathname from the
FSL (for example FSL serverX:/w/x where w is a junction), then we end up
looping forever.

Theresa

>  -----Original Message-----
>  From: Ellard, Daniel 
>  Sent: Tuesday, October 02, 2007 12:13 PM
>  To: Raj, Theresa; federated-fs at sdsc.edu
>  Subject: Re: [Federated-fs] FSN and filesets
>  
>  
>  
>  Maybe I'm missing something...  Here's my understanding of this.
>  
>  Let's say that our namespace is rooted at /a, and the client 
>  has mounted this from server R.  Let's say that /a/b is a 
>  junction to FSN X and /a/b/c is a junction to FSN Y.  Now 
>  the client tries to resolve /a/b/c.
>  
>  When the client hits R:/a/b, server R recognizes that this 
>  is a junction to FSN X. Server R does a resolve on X and 
>  finds the FSL serverX:/x, and so server R refers the client 
>  to continue the resolution there.
>  
>  The path that the client is trying to resolve is rewritten, 
>  as part of the referral so that instead of starting over at 
>  /a/b/c, the client starts over at the new path of /x/c, 
>  because that's where, on serverX, /a/b/c is.
>  
>  Now when the client tries to resolve /x/c and hits the 
>  junction c and the process repeats.  But (as long as the 
>  paths are properly formed) each step chips away at the path 
>  and we don't start again at the root.
>  
>  -Dan
>  
>  On 10/2/07 2:09 PM, "Raj, Theresa" <Theresa.Raj at netapp.com> wrote:
>  
>  > I might be missing something here, but I can't see how we can make 
>  > progress down a path.
>  > If a pathname on a destination fileserver has a non-leaf junction 
>  > component, then at that junction the fileserver gives out 
>  a referral 
>  > and the client resets the pathname lookup with the new 
>  FSL. Then again 
>  > when it hits the junction that caused the original 
>  referral, there is 
>  > another referral. So, we are back to the original FSL where the 
>  > pathname has  a intermediate junction component.
>  > 
>  > Clients might have a notion that they are doing lookups for a 
>  > referral, but servers don't. So the server will give out 
>  MOVED error 
>  > and a referral even for referral lookups.
>  > 
>  > If the above scenario that I mentioned is a possibility, 
>  then I'd like 
>  > some text about precluding intermediate junctions in the 
>  pathname in 
>  > FSLs.
>  > 
>  > Thanks,
>  > Theresa
>  > 
>  >>  -----Original Message-----
>  >>  From: Ellard, Daniel
>  >>  Sent: Tuesday, October 02, 2007 10:42 AM
>  >>  To: Raj, Theresa; federated-fs at sdsc.edu
>  >>  Subject: Re: [Federated-fs] FSN and filesets
>  >>  
>  >>  
>  >>  
>  >>  It's possible that resolution can traverse multiple  
>  junctions.  I 
>  >> don't think this is (necessarily) a problem,  as long as we make 
>  >> progress down the path.
>  >>  
>  >>  A hazard would be if the admin creates a junction that 
>  loops  back 
>  >> to one of its ancestors in the namespace, causing  
>  resolution to go 
>  >> into a loop.  (Do
>  >>  v4 clients recognize when they're going around in a referral
>  >>  look?)  We currently trust the admins to do the right thing
>  >>  -- should we do something stronger?
>  >>  
>  >>  -Dan
>  >>  
>  >>  
>  >>  On 10/2/07 1:23 PM, "Raj, Theresa" 
>  <Theresa.Raj at netapp.com> wrote:
>  >>  
>  >>> Ok.
>  >>> 
>  >>> I have a question about FSLs and the pathname that it 
>  provides. Is 
>  >>> there anything that percludes the admin from setting up
>  >>  this pathname
>  >>> such that one or more of its component is a junction? If
>  >>  this pathname
>  >>> has junction components then I'm afraid that clients will never 
>  >>> resolve this pathname and could keep ping ponging between
>  >>  fileservers.
>  >>> 
>  >>> Theresa
>  >>> 
>  >>>>  -----Original Message-----
>  >>>>  From: Ellard, Daniel
>  >>>>  Sent: Tuesday, October 02, 2007 8:25 AM
>  >>>>  To: Raj, Theresa; 'federated-fs at sdsc.edu'
>  >>>>  Subject: RE: [Federated-fs] FSN and filesets
>  >>>>  
>  >>>>  
>  >>>>  If that's the case, then that's something else that does
>  >>   need to be
>  >>>> distinguished!
>  >>>>  
>  >>>>  A junction represents the relationship between a
>  >>  directory  in one
>  >>>> fileset (or more generally, a node in the namespace)  and
>  >>  the root of
>  >>>> another fileset.  If filesets are the  building blocks, then 
>  >>>> junctions are the nails, or the glue  (pick your metaphor).
>  >>>>  
>  >>>>  -Dan
>  >>>>  
>  >>>>> -----Original Message-----
>  >>>>> From: Raj, Theresa
>  >>>>> Sent: Tuesday, October 02, 2007 11:18 AM
>  >>>>> To: Ellard, Daniel; federated-fs at sdsc.edu
>  >>>>> Subject: RE: [Federated-fs] FSN and filesets
>  >>>>> 
>  >>>>> It seems to me that junction is another term that is 
>  being used 
>  >>>>> interchangeably for a fileset.  Or at least, I haven't 
>  made the 
>  >>>>> distinction between a fileset and a junction.
>  >>>>> 
>  >>>>> Theresa
>  >>>>> 
>  >>>>>>  -----Original Message-----
>  >>>>>>  From: Ellard, Daniel
>  >>>>>>  Sent: Monday, October 01, 2007 12:34 PM
>  >>>>>>  To: federated-fs at sdsc.edu
>  >>>>>>  Subject: [Federated-fs] FSN and filesets
>  >>>>>>  
>  >>>>>>  
>  >>>>>>  The current document defines fileset first, and then FSN,
>  >>>>> and then
>  >>>>>> says that these two terms are used interchangably.
>  >>>>>>  I'd like to scrub the document and fix the usage to keep
>  >>>>> these terms
>  >>>>>> distinguished.  A fileset is the unit of  management and
>  >>>>> abstraction
>  >>>>>> for data, and a FSN is a name for  a fileset.  It's useful
>  >>>>> to be able
>  >>>>>> to distinguish between  the thing and the name of the thing.
>  >>>>>>  
>  >>>>>>  Thoughts?
>  >>>>>> -Dan
>  >>>>>>   
>  >>>>>>     
>  >>>>>>  
>  >>>>> 
>  >>>>  
>  >>  
>  >>  
>  
>