Graeme Stewart <[log in to unmask]> writes:
> 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
Until there is a pinning mechanism in place, then this makes good sense. Any
news on a timescale for this?
-Phil
|