[Arch-paper] Re: SFN + LFN + PFN

[Douglas Thain]

> The real issue is "name re-use".  If we can avoid that, that at least 
> will guarantee that you don't get the wrong file!  

Absolutely!  I'm not so worried about dealing with explicit failures due to
crashes, network losses, etc.  We all have experience dealing with those.  
However, name re-use is a pernicious problem that creeps in during the
design phase, and we need to work very hard to make sure that we don't
suffer from it.

> 
> Now, the issue I brought up of SFN + LFN + PFN has to do with yet another 
> desired feature: a single storage resource entity (referred to as a "site 
> storage resource manager") that manages multiple Storage Resources.  To satisfy 
> this feature, a file in the site can have a name (SFN) which is different from 
> the name of the file on a particular physical storage resource (PFN).  This is 
> a very useful concept, since the site-SRM can expose to the grid a single name 
> for a file, and move files around its physical storage resources as it sees 
> fit. Furthermore, a site-SRM can choose to "re-direct" a request to another SRM 
> under its control or to another SRM that cooperates with it.

Ok, I'm sorry for dragging the discussion away from this point.  ;)
I think it will be a necessary and powerful capability to allow the
referred-to storage sites to perform another level of indirection.

> As I said in my previous email, we can gloss over the "site SRM", and simple 
> state that a PFN can be mapped to another PFN by the storage resource manager.  
> But then the term "physical" is a bit misleading in that it is virtual-physical 
> as Ian pointed out, but I think we can live with that if we want to avoid "site 
> SRM" concepts.

Yes, good point.

Actually, I'd be interested to see more discussion of indirection at this
level.  Is it different in any fundamental way from the indirection
performed at the level of the replica manager?  Does it have different
requirements on consistency?