[Federated-fs] FSN and filesets
Erasani, Pranoop
Pranoop.Erasani at netapp.com
Wed Oct 3 12:34:33 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.
I probably didn't follow this discussion appropriately. Are you
suggesting that NFSv4 is capable enough to detect paths that have
junctions. I don't see how, NFSv4 (as in spec) in fact does not preclude
giving out any path.
It's upto implementations to restrict paths that can lead into circular
loops. Seems like Renu alluded to this. Just wanted to throw this
question out, just in case if I was missing something.
- Pranoop
> 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