[Federated-fs] Meeting notes

[Everhart, Craig]

> From: Ellard, Daniel 
> Sent: Thursday, April 10, 2008 3:03 PM
> To: federated-fs at sdsc.edu
> Subject: [Federated-fs] Meeting notes
> 
> ...
> 
> R2: If this requirement is satisfied by the NSDB, then some 
> of the sub-requirements are questionable.  There is feeling, 
> however, that those requirements are probably wrong anyway.  
> For example, requiring that when a fileset is taken offline 
> that its FSN->FSL mapping is removed is simply impractical 
> and creates failure conditions we don't want to deal with.  
> (it's OK to require that the server make an effort to clean 
> up when it makes a mess, but we can't require that no messes 
> ever occur.)  Similarly, the contract that the promoter must 
> confirm that an FSN->FSL mapping is valid before promoting it 
> is unenforcable.
> The server could crash in the midst of the operation.

Right.  I think the "Note that" paragraph can likely be removed.

> R8: This requirement is weakened.  R8a can be removed.  R8b 
> is probably not necessary (?); it should be replaced with 
> fixed, specified (as part of the protocol) annotations on the 
> FSLs.  Nobody can remember why R8c is necessary (any 
> theories) -- it probably served some purpose, but is it obsolete now?

R8c is there for management of the system: ideally an administrator
would be able to tell not just whether a given client/distributed path
name is a junction, but also the FSN that represents the junction.  This
would be useful for repairing a name space, for instance--to help clean
up after an unusual FSN deletion.  In such a case, a client would be
unable simply to navigate to the given path to see if it got referred
somewhere.

> If anyone has additional notes, please share!
> 
> Thanks,
> 	-Dan

		Craig