Sergio Andreozzi [mailto:sergio.andreozzi@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