> In response to some of Greig's ideas about SRMs handling more than one
> filetype through their interfaces (I agree) we might have to publish
> multiple SAs to represent each part of the SRM's capabilities. There's
> no reason I can see that the GlueSAPaths even need to be different
> (i.e., the actual storage model used is handled in the SRM v2
> transaction, not encoded into the SURL in some hokey way).
Yep, I agree with this. The concepts of permanent, volatile and durable
file/space types are internal to the SRM. How end users/experiments
view the robustness and reliability of a particular SRM is a different
matter entirely. This is why it would be good to know the storage setup at
each site (i.e. high end RAID 5 disk + hot spares + dual power
supplies...).
Identifying an SRM as providing only one GlueSAType (permanent, volatile
or durable) doesn't make sense since an SRM should be using all space
types to dynamically manage the space available to it.
Cheers,
Greig
--
=======================================================================
Dr Greig A Cowan http://www.ph.ed.ac.uk/~gcowan1
School of Physics, University of Edinburgh, James Clerk Maxwell Building
TIER-2 STORAGE SUPPORT PAGES: http://wiki.gridpp.ac.uk/wiki/Grid_Storage
=======================================================================
|