[Federated-fs] FSN and filesets
Ellard, Daniel
Daniel.Ellard at netapp.com
Wed Oct 3 12:40:00 PDT 2007
No, not at all. NFSv4 has no concept of junctions, and our job is to
keep it that way.
What I meant is that v4 is perfectly happy to go through multiple
referrals for a single path. There's no requirement that, in the case
where there's a referral, the referral point the client at the "right"
server. Traversing a path might generate a referral for every component
of the path.
-Dan
> -----Original Message-----
> From: Erasani, Pranoop
> Sent: Wednesday, October 03, 2007 3:35 PM
> To: Ellard, Daniel; Renu Tewari; Raj, Theresa
> Cc: federated-fs at sdsc.edu
> Subject: RE: [Federated-fs] FSN and filesets
>
> > 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