This contradicts previous advice (possibly only within London Tier2) that
we should declare our SE as volatile if it isn't backed up.
Rather than me changing my SE back and forth, I'll wait for UKI to
consider this and then provide definitive advice - please!
Cheers,
Simon
On Wed, 5 Oct 2005, Graeme Stewart wrote:
> On Wednesday 05 Oct 2005 09:13, Gordon, JC (John) wrote:
> >
> > I think it would be irresponsible of sysadmins (even collectively) to
> > define SEs as volatile without making sure experiments are aware of the
> > implications and that they are actually taking some action on the value.
>
> At the moment, with srm_v1, the experiments just don't have the functionality
> required to manage volatile space - they can't set the pin times. This may
> change once srv_v2 is rolled out, but at the moment all storage should be
> marked "permanent". N.B. this does not mean _immutable_ or _archived_, the
> VOs can, and should, manage the files and delete them when necessary. (VOs do
> know hardware failures happen.)
>
> See http://wiki.gridpp.ac.uk/wiki/SRM_file_types
>
> One way to stop a bad VO from filling up all storage at your site it to
> restrict access to pools on a per-VO basis:
>
> DPM: http://wiki.gridpp.ac.uk/wiki/DPM_VO_Specific_Pools
>
> dCache:
> http://wiki.gridpp.ac.uk/wiki/DCache_FAQ#How_do_I_map_a_VO_to_a_pool.3F
>
> Graeme
>
> --
> --------------------------------------------------------------------
> Dr Graeme Stewart http://www.physics.gla.ac.uk/~graeme/
> GridPP DM Wiki http://wiki.gridpp.ac.uk/wiki/Data_Management
>
|