[glue-wg] Updated thoughts...

Burke, S (Stephen) S.Burke at rl.ac.uk
Wed Apr 16 04:05:42 CDT 2008


Still getting back to some things ...

Felix Nikolaus Ehm [mailto:Felix.Ehm at cern.ch] said:
> > Perhaps opening a can of worms, but it may also be possible 
> > for a UserDomain to include services, i.e. you might have 
> > services registered in VOMS as well as users (even with 
> > delegated credentials you may want to give privileges to 
> > services which the users don't have).
> I strongly assume that this implies changing the main 
> entities (service ->userdomain relation).
> I'm not sure if we can do this before public comments deadline.

I'm not sure if it needs any change in the schema, but at least the
explanatory text could indicate the possibility.

> >   I'd also like to go back to the question I posed in one of 
> > the meetings ... say that a site implements Custodial/Online 
> > by ensuring three distinct disk copies, how would we 
> > represent that? What about mirrored RAID, how much space do 
> we record?
> If the storage system needs to keep more than one instance of 
> a file to
> ensure a certain storage quality of service then I don't feel this
> should be published into the grid information system.

Well, maybe - but for the standard LCG custodial/online (Disk1Tape1) we
*are* publishing both copies, at least assuming we publish the tape
sizes at all. Secondly there's an accounting issue, the VO is probably
going to be asked to pay for multiple permananent copies. Also there
could be an impact on the meaning of the free space - you may think you
have 100 Tb free but it may only be 50Tb if all files are duplicated. At
least I think we need a clear and consistent definition so people know
what to publish in a given case, e.g. if file sizes are published only
once as used space then the free space should be divided by any
duplication factor.

> Why should the
> user care if a system has theoretically 100GB but due to the QoS
> agreement (3 copies of a file) he can only use ~30GB?

Potentially the user cares twice: a) because they get charged more, and
b) because they have less free space than they thought (it's similar to
the "shared Share" argument).

> I'm not sure if we can define that a tape based storage system should
> have finite space in GLUE (although I would like to have it!) 

What I think we can define is that if you publish a size at all it
should be a finite number, and it should be the current capacity, i.e.
how many tapes are in the robot right now. If people don't or can't
publish it that's fine, but we shouldn't have people publishing
meaningless large numbers as some sites have done in the past, so when
you add up the storage in the whole Grid you get something silly - these
things sometimes get into high-level management presentations, where
someone just reads a number without realising that it can't be right!

Stephen


More information about the glue-wg mailing list