[glue-wg] Datastore proposal

Burke, S (Stephen) S.Burke at rl.ac.uk
Fri Apr 11 07:47:10 CDT 2008


Sergio Andreozzi [mailto:sergio.andreozzi at cnaf.infn.it] said:
> in this case, given a dataStore, I would not have define a separate 
> class for the size attributes. They can be directly added to the 
> dataStore class.

Yes. In fact the semantics may be a bit different too: I don't think
there's any need for ReservedSize as that's related to the SRM internals
and not the hardware, and similarly there's no need for a Cache type as
that relates to how it's used. So I think my proposed attributes are:

UniqueID: unique ID (or possibly we just need a LocalID?)

Name: Human-readable name (maybe indicating the technology, e.g.
StorageTek)

Type (disk, tape, ... - open enumeration) (or maybe call this attribute
Medium?)

Latency: Enumeration {Online, Nearline, Offline} (probably no need to
make this open?)

TotalSize: The total amount of data that can be stored (right now, e.g.
regardless of whether tapes may be added to order, but ignoring the
state so e.g. disk servers which are down still get counted). Note that
this could be smaller than the underlying hardware capacity, e.g. with
RAID the parity disks don't contribute to the size.

UsedSize: The total amount of data which is currently stored - this is
physical data, so e.g. if there are currently three copies of a file for
load-balancing then you count all of them.

FreeSize: TotalSize - UsedSize, i.e. the free space at the filesystem
level.

OtherInfo: any other information, e.g. on the technology (RAID6, LTO,
...). 

One other point, I looked back at the StorageComponent proposal and that
had a comment about hardware compression on tape drives. My initial
feeling is that we should stick to real physical numbers here, e.g. you
record a file as 2 Gb if it's that size on tape, even if it was 4 Gb
before compression. Maybe we should have an extra attribute to indicate
whether data may be compressed?

Stephen



More information about the glue-wg mailing list