[glue-wg] Some thoughts on storage objects

[Felix Nikolaus Ehm]

Hi Stephen,

Thanks for the comments. I've added some,too :-)

>  For Glue 2 the VOInfo seems to have turned into the Share, 
> at least judging by the attributes. However, that means that a 
> Share is *not* a space, and your slip above seems to suggest that 
> that's the way you're thinking. If several VOs shared a space 
> there would be several Shares - basically one Share per MappingPolicy,

> not one per space, although a MappingPolicy might consist of multiple
rules.

Generally, I think that comparisons between Glue 1.x and 2.0 are helpful
only to some extend. Concepts of 1.3 do not fit into 2.0 and therefore
the base for comparisons is not really given. Its more important to
agree on what we want to express.
In case of the VOInfo the information can be expressed by the
StorageMappingPolicy which describes how a VO may utilize a Share
representing storage space. Both keep StorageCapacity info to give
opportunity to distinguish more than one viewpoint of accounting. For
example, all sizes of mapping policies pointing to one share might not
sum up to the total size of the share. On the other hand: All associated
mapping policies generally should see the SAME free space as specified
in the Share. 
The Share also keeps capacity information in order not to run over all
mappingpolicies and count the (e.g.) usedSizes. There is also the case
of having no free space in the associated MappingPolicies but some free
published in the Share - not sure if this is makes sence. However, I
think that GLUE should not judge these specialities. They should be
treated by the instances which use the info.


> If anything represents a space in the SRM sense it would be the 
> Environment - but as I said in the previous mail that's become a bit 
> unclear since Environment now has no real attributes, just a type 
> which represents a storage class, so we're left with the ambiguity 
> (which we also ended up with in 1.3) of whether one Environment 
> represents all spaces of a given class, or whether you have one 
> per space (or maybe something else?).

The enviroment linked to the capacity was introduced to give an
summarized stats about the total spaces of all types of enviroments.
This does not neccessarily mean that all used spaces of the linked
shares should sum up to the (total) used space of the enviroment. On the
opposite it would be odd if you would publish a total size for the
environment which is lower than sum of the associated shares. This is a
known problem.

If you mean by SRM space something which is accessible via a
SpaceTokenDescription then the first way is to put it into the share.
All associated MappingPolicies would then see the same 'default' STD and
path (except, you'd specify a own 'non-default' path/STD in a
MappingPolicy).


> Maybe because we are trying to represent distinct concepts with 
> the same words, and maybe the same Glue objects? There are at 
> least two different underlying concepts: physical disk and tape 
> systems, and logical spaces (reservations) which may span many 
> instances of the physical storage, may be contained within them,
> and may be shared between VOs or not. (And which might perhaps be
nested ...)
> This was always a problem in glue and we never dealt with it. 
> For example, take a classic SE with a file system organised like:
>
> /data/atlas
> /data/lhcb
> ...
>
> each of which would be published as one SA. However, in terms of the 
> physical disk servers you might have one big server mounted at /data,
> n smaller ones mounted at /data/atlas, /data/lhcb, ... or m even
smaller 
> ones mounted at /data/atlas/mc, /data/atlas/cosmic/, ... or any 
> combination of those, and we had no way to describe those variations 
> in the schema. With SRM we no longer worry about that level of detail,

> but the general distinction between physical and logical space is
still there.

I understand your use case but is this an information system use case
for the future? I would say that this is rather a deployment issue than
something which needs to be published so that the middleware/user has to
take care of. 
In the case obove you would store on the server side all incoming files
under /data/atlas on server1, /data/cms/ under server2, etc.. Can this
be done like this or am I completly wrong?


Cheers,
	Felix

_______________________________________________
glue-wg mailing list
glue-wg at ogf.org
http://www.ogf.org/mailman/listinfo/glue-wg