Dear All,
After reading the thread I will attempt to summarise.
Currently D-cache setups by default (installed by YAIM) share storage
space across VO's. I believe the same is effectively true for DPM.
This leads to one VO using all the SE's space and this is a problem. I
see four solutions,
0 We demand Quotas
1 We allocate small spaces and reallocate these spaces by VO, with high
level tools to make this simple.
2 We use soft quotas to warn VO admins who and what is written by their
VO when they go over their soft quota in the information system.
3 We try and shoe horn SRM 2.2 spaces as quotas.
Problems
Solution 0
I am unconvinced that developers have time to implement quotas and srm 2.2
in time is realistic and want to save people time by thinking ahead.
Solution 1
This will not be optimal use of space as we will have fixed pool sizes
and VO's will need to get a multiple of these pools spread across the
storage hardware. Also scripts for working like this require pool
draining to WORK and be used by high level tools making admins life
easier. This cannot start until pool management is scriptable.
Solution 2
This will annoy people running jobs on Sunday/Monday morning when the the
sysadmins returns from the weekend and all these jobs fail as a VO has
used all the space on Saturday. Unless data can be automatically deleted
for VO's that over run their quota limit, or dynamically revoke permissions from
users who try to write to full servers, or move data to another site on
demand. I prefer deleting files or temporary revocation of rights to users
who attempt to write files above a quota ( We don't yet have separate roles
for deleting, reading and writing maybe VOMS will help ).
Solution 3
This may work as SRM spaces seem like quotas as implementations are
suggesting that although they look dynamic in the API they may be
static.
Conclusions.
Tier 1 sites do not have a problem with quotas as they have larger
servers so can accommodate hardware to quota service using existing
tools.
Managing a VO and/or a users space used is a required function for tier
2 operation, to prevent inexperienced users denying services to other
VO's and users. The current systems are not good enough and that if SRM
spaces are not dynamic they may indeed be quotas with another name. If
this is not the case then solutions 1 or 2 or both need to be applied
with the implications they bring.
We may need to say quota's are a requirement for the tier 2 site and let
developers and commissioners fight about priorities.
Regards
Owen Synge
|