[Federated-fs] FSN and filesets

[Everhart, Craig]

The contents of the FSL is substantially governed by the target NFSv4
protocol.  In NFSv4, you identify a filesystem (the target of a
referral) by identifying a server and a path-within-server for that
filesystem.  It's understood that that path-within-server will likely
bear no relationship to the paths that client-side applications will
see.

Basically, with this FSL data, we'll ultimately be passing it to an
NFSv4 client and telling it to connect to that server and start looking
for this file system at this server-side path.  Surely the target NFSv4
file server could think of lots of ways of denying service to that
server-side path.  Treating one of the components of that path as a
junction elsewhere is just one more interesting one.

But, more than likely, it will actually happen.  Think of this: server A
tells the client to go look for filesystem X at server B, with its
server-side path name being /a/b/c/d .  The client starts doing this.
Meanwhile, filesystem X is moved to server C, at its server-side path
name /e/f/g/h .  So the information given to the client is stale by the
time the client gets to using it.  One would hope that server B would in
fact notice that filesystem X is no longer present, and that it would
either know a better candidate location or it would go talk to the NSDB
service to find out.  Presuming that this lookup returns non-stale
information, we now have server B responding to requests about /a/b/c/d
with a referral to server C, path /e/f/g/h.  And this isn't that
byzantine a case.  What we have to do is ensure that the information
that server B gives out (possibly after getting it from an NSDB) is more
recent than the information that led to server B in the first place.

		Craig

> -----Original Message-----
> From: Raj, Theresa 
> Sent: Tuesday, October 02, 2007 1:24 PM
> To: Ellard, Daniel; federated-fs at sdsc.edu
> Subject: Re: [Federated-fs] FSN and filesets
> 
> 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
> >  > >   
> >  > >     
> >  > >
> >  >
> >  
>