[Federated-fs] FSN and filesets

Ellard, Daniel Daniel.Ellard at netapp.com
Wed Oct 3 06:57:22 PDT 2007 

I agree that it's best (in the sense of "most efficient") if the
exported path doesn't contain any junctions -- and if it does contain a
junction, it only makes sense for the junction to be the last component
of the path.  However, guaranteeing this is nontrivial, and I think that
the v4 referral protocol handles either case properly, so we don't need
to worry about it for v4.  This might be a more serious problem for v3
but I haven't thought about it enough yet.

-Dan 

> -----Original Message-----
> From: Renu Tewari [mailto:tewarir at us.ibm.com] 
> Sent: Wednesday, October 03, 2007 1:50 AM
> To: Raj, Theresa
> Cc: federated-fs at sdsc.edu
> Subject: Re: [Federated-fs] FSN and filesets
> 
> 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/2007
1002/185ff215/attachment.html 
>

More information about the Federated-fs mailing list