[Federated-fs] FSN and filesets

Renu Tewari tewarir at us.ibm.com
Tue Oct 2 22:49:34 PDT 2007


You raise a valid point. I think the point to note is that the the 
namespace path that the clients are traversing could be different from the 
path returned in fs_locations.  The path in fs_locations which is a path 
that has been exported by the server should not contain junctions to avoid 
the looping issue you raised.  The FSL path is this local path at the 
server  which should not contain junctions. 

renu
-
Sent by:        federated-fs-bounces at sdsc.edu
To:     "Ellard, Daniel" <Daniel.Ellard at netapp.com>, 
<federated-fs at sdsc.edu>
cc:      
Subject:        Re: [Federated-fs] FSN and filesets


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.sdsc.edu/pipermail/federated-fs/attachments/20071002/185ff215/attachment.html 


More information about the Federated-fs mailing list