Hi, I'll do this while it's fresh in my mind ... for those not in the meeting, the background is that we have a long-running debate about whether to represent the storage hardware explicitly in the schema. In the original Glue we had the Storage Library, which we then obsoleted because no-one used it. In the 1.3 discussion there was the proposed Storage Component, which we left out because we didn't get agreement on whether we needed it. Now we have the same discussion coming round again - the current draft has a Storage Resource to describe the software which manages some storage, e.g. Enstore or GPFS, but still nothing to represent the hardware it manages. The problem is that we never seem to have a clear use case that requires a hardware description, but it keeps coming back in discussions, perhaps because it's a natural way to think about storage systems. (Also LCG has specific hardware restrictions, e.g. that Custodial must imply tape storage, which are not mandated by SRM or described in the schema.) My proposal is to shortcut this discussion by putting a simple representation of the hardware in the schema, which would be optional for anyone to publish, so the debate can at least be pushed off to implementation time. I propose an object which I tentatively call a Datastore (or we could go back to the old StorageLibrary name if we want everything to start with "Storage"). A Datastore would represent some set of uniform managed storage hardware, e.g. a tape robot plus all the tapes, or a set of disk servers managed for the same purpose. For clarity, disk servers allocated e.g. to different VOs would still just constitute a single Datastore, but disk servers used for completely different purposes would be separate, e.g. the disk cache in front of the tape robot would be a different Datastore if managed independently of the Disk1 storage. The Datastore would have fairly few attributes: UniqueID (as usual) Name (human-readable name, maybe indicating the technology, e.g. StorageTek) Type (disk, tape, ... - open enumeration) Capacity (NB this is in the schema as a separate object for technical reasons but is really just an attribute) OtherInfo (as usual) It might perhaps be useful to give the technology, e.g. RAIDn for disk systems, but I think that should go in OtherInfo as it's likely to be hard to standardise it. This would be linked to the existing StorageResource object with a one-to-many relation, i.e. one Resource could manage many Datastores (Castor manages tape and disk) but not vice versa, one Datastore can only be managed by one Resource - if there are e.g. multiple sets of disk servers managed by several different software systems that would constitute multiple Datastores. The relation to StorageEnvironment and/or StorageShare remains open for discussion as there are other issues there (e.g. whether we want the Environment at all), but conceptually you would want a relation between the Share and whichever DataStore(s) store the data for that Share. That can be one to many, e.g. if Custodial/Online uses disk+tape, as in WLCG. Comments? Stephen
Hi Stephen, Burke, S (Stephen) wrote:
The Datastore would have fairly few attributes:
UniqueID (as usual)
Name (human-readable name, maybe indicating the technology, e.g. StorageTek)
Type (disk, tape, ... - open enumeration)
Capacity (NB this is in the schema as a separate object for technical reasons but is really just an attribute)
would this be 1-to-1 between DataStore and Capacity? - Sergio
The relation to StorageEnvironment and/or StorageShare remains open for discussion as there are other issues there (e.g. whether we want the Environment at all), but conceptually you would want a relation between the Share and whichever DataStore(s) store the data for that Share. That can be one to many, e.g. if Custodial/Online uses disk+tape, as in WLCG.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Sergio Andreozzi said: would this be 1-to-1 between DataStore and Capacity?
I'm inclined to say yes, the definition implies that the storage is homogeneous. I'm slightly wondering about Offline storage, i.e. where tapes are removed from the robot; my inclination would be to regard that as a separate Datastore, but possibly someone can think of a reason why not ... of course the people who think that publishing the capacity for Nearline storage is a bad idea will presumably think that Offline would be even more crazy, so it may well not matter in practice :) Stephen
Burke, S (Stephen) wrote:
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Sergio Andreozzi said: would this be 1-to-1 between DataStore and Capacity?
I'm inclined to say yes, the definition implies that the storage is homogeneous. I'm slightly wondering about Offline storage, i.e. where tapes are removed from the robot; my inclination would be to regard that as a separate Datastore, but possibly someone can think of a reason why not ... of course the people who think that publishing the capacity for Nearline storage is a bad idea will presumably think that Offline would be even more crazy, so it may well not matter in practice :)
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. Sergio
Stephen
-- Sergio Andreozzi INFN-CNAF, Tel: +39 051 609 2860 Viale Berti Pichat, 6/2 Fax: +39 051 609 2746 40126 Bologna (Italy) Web: http://www.cnaf.infn.it/~andreozzi
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
Hi Stephen, On Friday 11 April 2008 14:47:10 Burke, S (Stephen) wrote:
Sergio Andreozzi [mailto:sergio.andreozzi@cnaf.infn.it] said:
[size attributes] 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.
Yep, that sounds sensible to me, although ReservedSize may be a useful concept (see below).
So I think my proposed attributes are:
UniqueID: unique ID (or possibly we just need a LocalID?)
I think a LocalID should be sufficient.
Name: Human-readable name (maybe indicating the technology, e.g. StorageTek)
Yes, in principle; although I'd be weary of suggestion people put technology names into Name. I know this is just an example, but people tend to follow examples. People may naturally choose the technology as a Name anyway and there's nothing wrong with that. The problem, if it comes, would be that people then expect the technology to be embedded in the Name field. Perhaps we could suggest technology as something that might go in the OtherInfo field? (or is this just being too paranoid?)
Type (disk, tape, ... - open enumeration) (or maybe call this attribute Medium?)
This is definitely nit-picking, but for many instances this would be more "media". Using "type" would avoid the singular / plural issue (I think). That aside, either choice is OK.
Latency: Enumeration {Online, Nearline, Offline} (probably no need to make this open?)
Do we define what online, nearline and offline mean somewhere?
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).
Yes. Perhaps the "total amount of data that can stored without operator intervention and when operating correctly". Would that be sufficient?
Note that this could be smaller than the underlying hardware capacity, e.g. with RAID the parity disks don't contribute to the size.
Aye. We should record the storage actually available to end-users, the ten hot-spare disks shouldn't be recorded in that number.
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.
Ah, and we get into a slightly contentious issue. So, with dCache, a disk pool's storage can be logically split into five parts: precious precious&sticky cache cache&sticky free precious is the total size of all files that are to be stored on tape (but where this hasn't happened yet), e.g., D0T1. precious&sticky is the total size of all files that are to be stored on tape (but, again, this hasn't happened yet). Once stored they should be "pinned". e.g., D1T1. cache is the total size of all files that can be deleted at any time. cache&sticky is the total size of all files that cannot be deleted, e.g., pinned D0T1. free is axiomatically the space not described by the other four categories, i.e.: totalSize - (precious + precious&sticky + cache + cache&sticky). Stephen, your description seems to map to precious + precious&sticky + cache + cache&sticky. However, for most systems this should be ~100% of totalSize most of the time, so I'm not sure how useful that number is. Perhaps we can look at the free(1) command for some hints since they face a similar problem. Here's an example output (I've edited it for clarity). total used free buffers cached Mem: 2074992 1760664 314328 225920 1193968 -/+ buffers/cache: 340776 1734216 This says that memory used for buffers and cache (1419888 in total, for this example) is, in the first line, considered part of the used space. But, if considered free, would result in the second line. Perhaps we should publish two numbers? Or, we could publish a reservedSize (corresponding to buffers+cached above). People add this number to either the usedSize or the freeSize depending what they want to know.
FreeSize: TotalSize - UsedSize, i.e. the free space at the filesystem level.
Is this an axiomatic relationship? If so, it probably isn't worth recording it.
OtherInfo: any other information, e.g. on the technology (RAID6, LTO, ...).
Yup, sounds good, provided it's optional information.
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?
OK, I think this is a can-o-worms that we don't want to open. I had a chat with our local tape people and here are some comments: 1. files are often compressed in the user-domain, if this is so then the drive might disable compression altogether (it checks whether the uncompressed version is less that the compressed size). If compressed, the compression ratio is typically very low (~1%). Either cases for many files the compressed size ~= actual size, so there's no real distinction. This is strongly dependant on the file structure and, by implication on the UserDomain. 2. for some tape systems, it would be very difficult to obtain the actual storage usage (the "tape occupancy"?). 3. sometimes a file store operation can fail. If so, the tape software may retry, but some (potentially unknown) fraction of the file has been written to tape. Does this count towards to actual occupancy? 4. I believe Castor had an issue when deleting files (leading to "repacking"?) If we're attempting to account for actual yardage of tape used, how would this be accounted? [for disks, this is dealt with through fragmentation] I think the only thing we can publish is the (user-domain) file size that has been recorded to tape. I believe this is the actual number people are interested. If a site has some cunning compression system so they can squeeze the files into 1% of their original size, that's a site-local issue and shouldn't be published in Glue. (just my 2c worth). Cheers, Paul.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said:
Name: Human-readable name (maybe indicating the technology, e.g. StorageTek)
Yes, in principle; although I'd be weary of suggestion people put technology names into Name.
Yes, this is always difficult, and I think the schema document should make a general statement about IDs and Names that they should never contain any metadata to be parsed by a program. However, in practice they always do contain things that humans will recognise, so it may as well be something that helps a human understand what's going on - especially for Names which are explicitly supposed to be for human consumption, e.g. in monitoring displays. In practice sites probably have some internal name for many of these things anyway.
Type (disk, tape, ... - open enumeration) (or maybe call this attribute Medium?)
This is definitely nit-picking, but for many instances this would be more "media". Using "type" would avoid the singular / plural issue (I think).
I think this is just because computer people misuse language - it's correct to describe tape as a storage medium, singular, and the fact that people refer to "media" meaning "a bunch of tapes" is incorrect.
Latency: Enumeration {Online, Nearline, Offline} (probably no need to make this open?)
Do we define what online, nearline and offline mean somewhere?
SRM does - probably we should copy it. However, I think it isn't really an SRM-specific term, it should be general enough to use with other things, hence my suggestion that the enumeration can be closed. In theory I suppose you could have levels of nearline-ness according to how long the latency really is, but I doubt that we need to worry about it.
Perhaps the "total amount of data that can stored without operator intervention and when operating correctly". Would that be sufficient?
Something like that. In general we should spell things out as much as possible, people can be very creative in misinterpreting definitions :)
Aye. We should record the storage actually available to end-users, the ten hot-spare disks shouldn't be recorded in that number.
Indeed.
Stephen, your description seems to map to precious + precious&sticky + cache + cache&sticky. However, for most systems this should be ~100% of totalSize most of the time, so I'm not sure how useful that number is.
I'm inclined to think that's correct here: if we're describing the real hardware and it really is full of files then that's fine. The hardware doesn't care what the SRM thinks the files are for (or who they belong to). This kind of distinction is more of a problem for the other places we use Capacities, and indeed is the reason we get so much argument about what to publish.
Perhaps we should publish two numbers?
No, I don't think so; if we want this information at all it should be attached to the SRM-level objects like Share and Environment, because the SRM is what knows that one file is in a cache and another is precious.
FreeSize: TotalSize - UsedSize, i.e. the free space at the filesystem level.
Is this an axiomatic relationship? If so, it probably isn't worth recording it.
That's another perennial debate - traditionally we've gone with publishing the complete set even if you can derive one of them from the others, rather than forcing clients to do the sums. You can see the same kind of thing on the CE side, e.g. TotalJobs = RunningJobs + WaitingJobs. As always it's optional so a given grid or info provider may not in fact publish all of them. [Hardware compression]
OK, I think this is a can-o-worms that we don't want to open.
Well, we have to open it at least part way, otherwise we leave the definition ambiguous, and you can bet that different people would make different choices :)
2. for some tape systems, it would be very difficult to obtain the actual storage usage (the "tape occupancy"?).
Maybe, but then you just wouldn't publish it. The reason I went for that definition is that the alternative would create numbers which are hard to interpret, e.g. UsedSize > TotalSize - the compression factor is variable so it doesn't make sense to scale the TotalSize. Also it seems to me that something in the system must know what the occupancy is, otherwise how can it decide whether a new file can be written to a given tape?
3. sometimes a file store operation can fail. If so, the tape software may retry, but some (potentially unknown) fraction of the file has been written to tape. Does this count towards to actual occupancy?
In principle I'd argue that it should reduce the TotalSize, in practice you'd probably just ignore it - you can never expect to fill your storage 100%.
4. I believe Castor had an issue when deleting files (leading to "repacking"?) If we're attempting to account for actual yardage of tape used, how would this be accounted?
I think that's the same kind of thing, it may be that some of your "free" space is not actually usable in practice. I think it would be much too complicated to try to represent that explicitly - bear in mind that this is just supposed to be a simple definition of an object we probably don't need at all!
I think the only thing we can publish is the (user-domain) file size that has been recorded to tape. I believe this is the actual number people are interested.
It's what they're interested in when they look at e.g. the Share, and what they should find there. If they want to look at a hardware description (which they may well not) they should see the hardware numbers ... Stephen
Hi, most of the things I have commented should find their validity not only in this [StorageStorage|StorageDatastore] discussion but also in the general context of GLUE 2.0 storage schema.
-----Original Message----- From: glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Burke, S (Stephen) Sent: Freitag, 11. April 2008 23:42 To: Paul Millar; glue-wg@ogf.org Subject: Re: [glue-wg] Datastore proposal
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Paul Millar said:
Name: Human-readable name (maybe indicating the technology, e.g. StorageTek)
Yes, in principle; although I'd be weary of suggestion people put technology names into Name.
Yes, this is always difficult, and I think the schema document should make a general statement about IDs and Names that they should never contain any metadata to be parsed by a program. However, in practice they always do contain things that humans will recognise, so it may as well be something that helps a human understand what's going on - especially for Names which are explicitly supposed to be for human consumption, e.g. in monitoring displays. In practice sites probably have some internal name for many of these things anyway.
Type (disk, tape, ... - open enumeration) (or maybe call this attribute Medium?)
This is definitely nit-picking, but for many instances this would be more "media". Using "type" would avoid the singular / plural issue (I think).
I think this is just because computer people misuse language - it's correct to describe tape as a storage medium, singular, and the fact that people refer to "media" meaning "a bunch of tapes" is incorrect.
I don't know what computer people are, but I agree that 'media' is the appropriate word to use in such context.
Latency: Enumeration {Online, Nearline, Offline} (probably no need to make this open?)
Do we define what online, nearline and offline mean somewhere?
SRM does - probably we should copy it. However, I think it isn't really an SRM-specific term, it should be general enough to use with other things, hence my suggestion that the enumeration can be closed. In theory I suppose you could have levels of nearline-ness according to how long the latency really is, but I doubt that we need to worry about it.
Perhaps the "total amount of data that can stored without operator intervention and when operating correctly". Would that be sufficient?
Something like that. In general we should spell things out as much as possible, people can be very creative in misinterpreting definitions :)
Aye. We should record the storage actually available to end-users, the ten hot-spare disks shouldn't be recorded in that number.
Indeed.
Yupp.
Stephen, your description seems to map to precious + precious&sticky + cache + cache&sticky. However, for most systems this should be ~100% of totalSize most of the time, so I'm not sure how useful that number is.
I'm inclined to think that's correct here: if we're describing the real hardware and it really is full of files then that's fine. The hardware doesn't care what the SRM thinks the files are for (or who they belong to). This kind of distinction is more of a problem for the other places we use Capacities, and indeed is the reason we get so much argument about what to publish.
Perhaps we should publish two numbers?
No, I don't think so; if we want this information at all it should be attached to the SRM-level objects like Share and Environment, because the SRM is what knows that one file is in a cache and another is precious.
FreeSize: TotalSize - UsedSize, i.e. the free space at the filesystem level.
Is this an axiomatic relationship? If so, it probably isn't worth recording it.
That's another perennial debate - traditionally we've gone with publishing the complete set even if you can derive one of them from the others, rather than forcing clients to do the sums. You can see the same kind of thing on the CE side, e.g. TotalJobs = RunningJobs + WaitingJobs. As always it's optional so a given grid or info provider may not in fact publish all of them.
[Hardware compression]
OK, I think this is a can-o-worms that we don't want to open.
Well, we have to open it at least part way, otherwise we leave the definition ambiguous, and you can bet that different people would make different choices :)
2. for some tape systems, it would be very difficult to obtain the actual storage usage (the "tape occupancy"?).
Maybe, but then you just wouldn't publish it. The reason I went for that definition is that the alternative would create numbers which are hard to interpret, e.g. UsedSize > TotalSize - the compression factor is variable so it doesn't make sense to scale the TotalSize.
Also it seems to me that something in the system must know what the occupancy is, otherwise how can it decide whether a new file can be written to a given tape?
For CASTOR this information is available and kept in the "VolumeManager" tables. I strongly assume that this information can be obtained somehow from storage systems which have a tape backend. (see also next comment)
3. sometimes a file store operation can fail. If so, the tape software may retry, but some (potentially unknown) fraction of the file has been written to tape. Does this count towards to actual occupancy?
In principle I'd argue that it should reduce the TotalSize, in practice you'd probably just ignore it - you can never expect to fill your storage 100%.
This tape space is used and is not available until the tape has been repacked. But I agree with Stephen and I am sure it is fine that in GLUE we don't care about this number. The opposite is that we would publish the 'lost' space (due to errors) of such system in GLUE - ugly! Also, HSM with tape backend do have monitoring tools to see how much tape space is left (I don't think that e.g. CASTOR Tape Operations considers the lost space as 'theoretically free'). This number can then be published into GLUE.
4. I believe Castor had an issue when deleting files (leading to "repacking"?) If we're attempting to account for actual yardage of tape used, how would this be accounted?
well, its the nature of tapes and of how data is written. Other HSM with tape should have the same problems. (Except they will seek over the tape to find a suitable space for a given file)
I think that's the same kind of thing, it may be that some of your "free" space is not actually usable in practice. I think it would be much too complicated to try to represent that explicitly - bear in mind that this is just supposed to be a simple definition of an object we probably don't need at all!
I think the only thing we can publish is the (user-domain) file size that has been recorded to tape. I believe this is the actual number people are interested.
It's what they're interested in when they look at e.g. the Share, and what they should find there. If they want to look at a hardware description (which they may well not) they should see the hardware numbers ...
As you say it: we want to cover in GLUE the big portion of use cases. This hardware level view -especially from users- doesn't appear to me as a main one. Please correct me if I am wrong. I'll then incorporate it into the Use-Case document. Cheers, Felix
Hi all, Some quick comments, as its Friday and late... On Friday 11 April 2008 18:45:22 Felix Nikolaus Ehm wrote:
Also it seems to me that something in the system must know what the occupancy is, otherwise how can it decide whether a new file can be written to a given tape?
For CASTOR this information is available and kept in the "VolumeManager" tables.
[obtaining tape storage information, such as totalSize]
I strongly assume that this information can be obtained somehow from storage systems which have a tape backend. [...] Also, HSM with tape backend do have monitoring tools to see how much tape space is left (I don't think that e.g. CASTOR Tape Operations considers the lost space as 'theoretically free'). This number can then be published into GLUE.
Yes, the problem here is not that the numbers aren't recorded somewhere: I believe they are (but, of course, could be wrong!). The problem is more that there might be no tools to extract the information, so no way of pulling this information out (short of hacking proprietary database formats, which isn't fun). This is what concerns me most about publishing information about tape systems. My impression is that some operate like a black-box and obtaining meaningful numbers will be either difficult, very difficult or "impossible". Of course, I'm happy if others can publish this information, and maybe obtaining this information isn't such a problem so we, too, can provide this information. But I feel these attributes, if included, should be marked as optional so people don't rely on them. Cheers, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
But I feel these attributes, if included, should be marked as optional so people don't rely on them.
In the current draft everything except the UniqueID is optional - although I might argue that Type should be mandatory, otherwise there wouldn't be much point in publishing the object at all. Incidentally, the draft is missing Name (not too important) and also Latency, which is more important since one of the reasons for doing this is to make the LCG link between storage class and technology more explicit. Stephen
On Wednesday 09 April 2008 16:14:36 Burke, S (Stephen) wrote: [snip!]
A Datastore would represent some set of uniform managed storage hardware,
Sounds OK.
e.g. a tape robot plus all the tapes, or a set of disk servers managed for the same purpose.
So, if some site offers some disks that provide a custodial-like service and others that provide replica-like service, they would be represented as separate Datastore objects, right? Or is more the difference between disk used for caching and disk used as part of UserDomain's allocated space (D1T1, D1T0)? Playing devil's advocate here, what if a site had a set of disks that could provide either a custodial- or replica-like service (e.g. resilient mode with dCache)?
For clarity, disk servers allocated e.g. to different VOs would still just constitute a single Datastore, but disk servers used for completely different purposes would be separate, e.g. the disk cache in front of the tape robot would be a different Datastore if managed independently of the Disk1 storage.
OK, but it would be equally OK to publish all disk storage as one big generic "disk" Datastore, right?
The Datastore would have fairly few attributes: [...] Type (disk, tape, ... - open enumeration)
... which we would define the common types, right?
[...] Capacity (NB this is in the schema as a separate object for technical reasons but is really just an attribute)
Would it make sense to embed the numbers as attributes, rather than have them as a separate object? If totalSize, usedSize, etc. are all, at most, single-valued for a Datastore, then simply having these numbers as attributes might make more sense.
OtherInfo (as usual)
It might perhaps be useful to give the technology, e.g. RAIDn for disk systems, but I think that should go in OtherInfo as it's likely to be hard to standardise it.
Agreed. Within a grid, they might come up with a standardised method of expressing the technology. In fact, this might become something of a folkonomy.
This would be linked to the existing StorageResource object with a one-to-many relation, i.e. one Resource could manage many Datastores (Castor manages tape and disk) but not vice versa, one Datastore can only be managed by one Resource - if there are e.g. multiple sets of disk servers managed by several different software systems that would constitute multiple Datastores.
OK, I think, but it might depend on the "management" aspect of Datastores.
The relation to StorageEnvironment and/or StorageShare remains open for discussion as there are other issues there (e.g. whether we want the Environment at all), but conceptually you would want a relation between the Share and whichever DataStore(s) store the data for that Share. That can be one to many, e.g. if Custodial/Online uses disk+tape, as in WLCG.
How about, instead of associating the StorageShare with the Datastore, there was a link between the StorageCapacity (associated with a StorageShare) to the Datastore? This link would be optional one-to-many: each StorageShare is associated with a single Datastore (0..1 multiplicity) and each Datastore is associated with any number of StorageShares (0..* multiplicity). Would that be acceptable? Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
So, if some site offers some disks that provide a custodial-like service and others that provide replica-like service, they would be represented as separate Datastore objects, right?
Probably, but it depends how it's implemented. If the system decides dynamically where to put files in a common set of hardware regardless of the RP it would all be one Datastore. However, I suspect it would be more common to have separate hardware. At some level this relates to the discussion about whether the Share.RP can be multivalued.
Or is more the difference between disk used for caching and disk used as part of UserDomain's allocated space (D1T1, D1T0)?
Again I think it's a matter of implementation. Usually I'd expect cache disks to be physically distinct, but maybe sometimes they aren't - perhaps it could be useful to allow a cache to overflow into the free space of permanent storage.
OK, but it would be equally OK to publish all disk storage as one big generic "disk" Datastore, right?
If it's all managed by a single Resource, yes. The difference you would get from splitting a homogenous Datastore into pieces would be from the relation to the Share, so it would only matter at all if different Shares mapped to distinct disk servers, and in any case you have the size information at the share level.
Type (disk, tape, ... - open enumeration)
... which we would define the common types, right?
Yes - but do we have anything common apart from tape and disk? dvd?
one Datastore can only be managed by one Resource - if there are e.g. multiple sets of disk servers managed by several different software systems that would constitute multiple Datastores.
OK, I think, but it might depend on the "management" aspect of Datastores.
Can you elaborate? As I said earlier we have the situation at RAL that all the different Castor instances (Resources) share a common tape system, but I think that's too complicated to deal with, we should just treat it as multiple tape Datastores.
How about, instead of associating the StorageShare with the Datastore, there was a link between the StorageCapacity (associated with a StorageShare) to the Datastore?
Well, partly that's back to the same discussion about Capacity (currently called StorageShareState) being treated as a separate object or not. In my view of how this works it doesn't make sense to have an independent relation to a Capacity, it's the same thing as a relation to the parent object. There is an implicit relationship, e.g. if a Share has a Capacity/State with types online and nearline (and/or cache and nearline) then you would expect the Share to be related to Datastores with Latencys online and nearline. However, as discussed many times there is no requirement to publish the Capacitys, and especially not for tape, so in principle you could have an online/custodial Share which doesn't publish a nearline Capacity but is nevertheless related to a nearline Datastore.
This link would be optional one-to-many: each StorageShare is associated with a single Datastore (0..1 multiplicity) and each Datastore is associated with any number of StorageShares (0..* multiplicity).
Would that be acceptable?
Well ... rather than making Share <-> Datastore *..* you could consider defining three separate Share <-> Datastore relations, one for each of Online, Nearline and Offline, and each of which would be *..1. However, that would imply that the storage for a Share for a given Latency can only be provided by one Datastore, and I suspect that you can't be sure of that in all cases. An example could be LCG-style Online/Custodial D1T1 where you have three Datastores: tape, disk cache in front of the tape, and permanent disk (I think this is what CNAF has?). Stephen
Burke, S (Stephen) wrote:
Type (disk, tape, ... - open enumeration)
... which we would define the common types, right?
Yes - but do we have anything common apart from tape and disk? dvd?
I think we should at least foresee dvd, and keep it open-ended.
one Datastore can only be managed by one Resource - if there are e.g. multiple sets of disk servers managed by several different software systems
that would constitute multiple Datastores.
OK, I think, but it might depend on the "management" aspect of Datastores.
Can you elaborate? As I said earlier we have the situation at RAL that all the different Castor instances (Resources) share a common tape system, but I think that's too complicated to deal with, we should just treat it as multiple tape Datastores.
Agreed.
This link would be optional one-to-many: each StorageShare is associated with a single Datastore (0..1 multiplicity) and
I may have commented on that proposal already: I do not agree with it. A StorageShare can be associated with several (independent) Datastores, each providing a storage technology that is needed by the Share. For example, one Datastore for the disk and another for the tape.
each Datastore is associated with any number of StorageShares (0..* multiplicity).
Would that be acceptable?
Well ... rather than making Share <-> Datastore *..* you could consider defining three separate Share <-> Datastore relations, one for each of Online, Nearline and Offline, and each of which would be *..1. However, that would imply that the storage for a Share for a given Latency can only be provided by one Datastore, and I suspect that you can't be sure of that in all cases. An example could be LCG-style Online/Custodial D1T1 where you have three Datastores: tape, disk cache in front of the tape, and permanent disk (I think this is what CNAF has?).
For D1T1 we should not publish any hidden cache in front of the tape: that cache is an optimization that the client has no control over (one cannot pin files in it). Can we collapse the tape with the cache into a single Datastore that has both an Online and a Nearline component? If not, I suppose we can collapse cache with disk if we do not care about the semantic differences at that level.
art from tape and disk? dvd?
I think we should at least foresee dvd, and keep it open-ended Don't forget holographic storage
http://www.inphase-technologies.com/products/media.asp?subn=3_2
Laurence Field wrote:
I think we should at least foresee dvd, and keep it open-ended
Don't forget holographic storage
http://www.inphase-technologies.com/products/media.asp?subn=3_2
Should we add "optical" as a generic term for optical storage?
Maarten Litmaath [mailto:Maarten.Litmaath@cern.ch] said:
Should we add "optical" as a generic term for optical storage?
What are the characteristics of holographic storage - is it significantly different to DVD? I don't see any comparison on the web site with tapes or dvds ... Stephen
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Maarten Litmaath said: Can we collapse the tape with the cache into a single Datastore that has both an Online and a Nearline component?
I would say not, the basic idea of a Datastore is to make it homogeneous. Is there a real problem with having a many-to-many relation between Share and Datastore? In LDAP I think it's OK, you just put pointers in the objects as appropriate, i.e. a Share has ForeignKeys pointing to all of its related Datastores (and you could have pointers the other way as well, Datastore to Share, but I'm not sure it's necessary). Does that give a significant problem in the other technologies? For relational implementations you'd need an intermediate table but it's not that bad (we have that for all multivalued attributes anyway). For XML I don't know how it works. Stephen
On Thu, 17 Apr 2008, Burke, S (Stephen) wrote:
Can we collapse the tape with the cache into a single Datastore that has both an Online and a Nearline component?
I would say not, the basic idea of a Datastore is to make it homogeneous. Is there a real problem with having a many-to-many relation between Share and Datastore? In LDAP I think it's OK, you just put
No, I do not have a problem with that. My point is that the very same facility that provides the tape may at the same time control the disk: the disk would just be the online component of the tape store, and not something that one has to foresee separately, if desired. In principle a tape store does not _have_ to have disk (e.g. central data recording in CASTOR-1 could write directly to tape), but if it has disk, that disk is directly managed by the same software that manages the tape, so I felt we might want to express that explicitly by putting an online component alongside the nearline component of the DataStore.
On Thu, 17 Apr 2008 Maarten.Litmaath@cern.ch wrote:
On Thu, 17 Apr 2008, Burke, S (Stephen) wrote:
Can we collapse the tape with the cache into a single Datastore that has both an Online and a Nearline component?
I would say not, the basic idea of a Datastore is to make it homogeneous. Is there a real problem with having a many-to-many relation between Share and Datastore? In LDAP I think it's OK, you just put
No, I do not have a problem with that. My point is that the very same facility that provides the tape may at the same time control the disk: the disk would just be the online component of the tape store, and not something that one has to foresee separately, if desired.
In principle a tape store does not _have_ to have disk (e.g. central data recording in CASTOR-1 could write directly to tape), but if it has disk,
...for a T1D0 storage class...
that disk is directly managed by the same software that manages the tape, so I felt we might want to express that explicitly by putting an online component alongside the nearline component of the DataStore.
_______________________________________________ glue-wg mailing list glue-wg@ogf.org http://www.ogf.org/mailman/listinfo/glue-wg
Maarten.Litmaath@cern.ch [mailto:Maarten.Litmaath@cern.ch] said:
No, I do not have a problem with that. My point is that the very same facility that provides the tape may at the same time control the disk: the disk would just be the online component of the tape store, and not something that one has to foresee separately, if desired.
Isn't that the point of having the Resource? That represents the management system, and is linked to N Datastores each of which represents a homogeneous pool of storage. You can choose not to publish some or all of the Datastores, but I don't see any gain from merging them together, it would just take us back to the complexity we're trying to disentangle (i.e. what kind of physical storage is used where). Stephen
Hi all, Laurence suggested we might rename DataStore to StorageEnvironment! Would be OK for me...
Maarten Litmaath [mailto:Maarten.Litmaath@cern.ch] said:
Laurence suggested we might rename DataStore to StorageEnvironment! Would be OK for me...
Just to maximise the chance of confusion :) I suppose it's OK if we really must have everything prefixed with Storage, but I still prefer Datastore ... Stephen
On Thu, 17 Apr 2008, Burke, S (Stephen) wrote:
Laurence suggested we might rename DataStore to StorageEnvironment! Would be OK for me...
Just to maximise the chance of confusion :) I suppose it's OK if we really must have everything prefixed with Storage, but I still prefer Datastore ...
The idea was that Environment would better mimic the CE schema. DataStore (with capital 'S'?) is fine too.
glue-wg-bounces@ogf.org
[mailto:glue-wg-bounces@ogf.org] On Behalf Of Burke, S (Stephen) said: This would be linked to the existing StorageResource object with a one-to-many relation, i.e. one Resource could manage many Datastores (Castor manages tape and disk) but not vice versa, one Datastore can only be managed by one Resource - if there are e.g. multiple sets of disk servers managed by several different software systems that would constitute multiple Datastores.
One more thing while I think of it before I give up for the night ... I realised that at RAL we already have something more complicated than this. There is a separate castor instance for each of atlas, cms and lhcb, plus one for everyone else. Those instances have separate disk pools, hence they are separate Resources with separate Datastores. However, there is only one tape system shared between all of them, which would imply one Resource and one Datastore. I think the root of the problem is that the Resource can in fact be a hierarchy, Castor manages disk directly but the tape part goes through another layer of software. Whether or how we want to represent that I'm not sure ... probably just have a separate tape Datastore per instance regardless?
relation between the Share and whichever DataStore(s) store the data for that Share. That can be one to many, e.g. if Custodial/Online uses disk+tape, as in WLCG.
Of course I meant many to many, obviously one Datastore contains many Shares. Stephen
On Friday 11 April 2008 03:36:21 Maarten.Litmaath@cern.ch wrote:
On Wed, 9 Apr 2008, Burke, S (Stephen) wrote:
[...] I propose an object which I tentatively call a Datastore (or we could go back to the old StorageLibrary name if we want everything to start with "Storage"). [...]
StorageSupply ?
Although perhaps strictly redundant, all the other objects have Storage as a prefix, so perhaps we should try to continue this. I'm not a fan of StorageLibrary as, to me, it sounds quite tape-specific (people tend not to talk about libraries of disks, right?). StorageSupply would be OK; but for me, "supply" doesn't hint strongly that it's the physical medium/media we're referring to. I did a quick hunt through an online thesaurus. Would one of these be useful? StorageRepository StorageVault StorageSource StorageBase StorageArchive StorageWarehouse Cheers, Paul. (or we could just call it StorageStash)
Paul Millar [mailto:paul.millar@desy.de] said:
StorageSupply ?
I don't really like that, it doesn't convey the idea of representing the hardware.
I'm not a fan of StorageLibrary as, to me, it sounds quite tape-specific (people tend not to talk about libraries of disks, right?).
Perhaps not, but I'm not sure there's a good reason why you can't. Possibly it's just a visual thing, tapes in racks look like a library and disk racks don't?
StorageSupply would be OK; but for me, "supply" doesn't hint strongly that it's the physical medium/media we're referring to.
Indeed.
I did a quick hunt through an online thesaurus. Would one of these be useful?
StorageRepository StorageVault StorageSource StorageBase StorageArchive StorageWarehouse
Of those I'd be inclined to go for StorageVault, partly because it's short. Also it somewhat conveys the right idea, while being sufficiently exotic that you realise that it's a specialised term. And while it does have some extra connotations (vampires? :) they don't really relate to computing, whereas e.g. Archive would suggest something that would be read infrequently. Repository would be my second choice, but it's longer and to me at least fairly meaningless. Stephen PS http://www.productsandservices.bt.com/consumerProducts/displayProduct.do ?productId=CON-3291
Burke, S (Stephen) wrote:
StorageRepository StorageVault StorageSource StorageBase StorageArchive StorageWarehouse
Of those I'd be inclined to go for StorageVault, [...]
I do not like that one very much, because to me it suggests being an offline storage room for tapes. StorageCollection StorageFacility StorageGroup StorageHardware StorageMedia StorageProvision StorageReservoir StorageSet
Maarten Litmaath [mailto:Maarten.Litmaath@cern.ch] said:
I do not like that one very much, because to me it suggests being an offline storage room for tapes.
StorageCollection StorageFacility StorageGroup StorageHardware StorageMedia StorageProvision StorageReservoir StorageSet
I think you're mainly convincing me that Datastore is the best name, regardless of not starting with "Storage"! Stephen
Hi all, On Friday 11 April 2008 12:48:06 Maarten Litmaath wrote:
Burke, S (Stephen) wrote: [...]
Of those I'd be inclined to go for StorageVault, [...]
I do not like that one very much, because to me it suggests being an offline storage room for tapes.
FWIW, I took a quick straw poll from people in the offices nearby, listing all the suggestions so far (err..., except StorageLibrary and Datastore, now that I think of it). Three people favoured StorageMedia and one chose StorageReservoir. HTH, Paul.
Paul Millar [mailto:paul.millar@desy.de] said:
FWIW, I took a quick straw poll from people in the offices nearby, listing all the suggestions so far (err..., except StorageLibrary and Datastore, now that I think of it). Three people favoured StorageMedia and one chose StorageReservoir.
Hmm ... Media is possible I suppose, although e.g. it focusses on the tapes rather than the robot, or disks rather than servers. Reservoir sounds very odd ... I think I still prefer Datastore. (StorageDatastore?!) Stephen PS Or just call it Storage ... (or StorageStorage :)
participants (7)
-
Burke, S (Stephen) -
Felix Nikolaus Ehm -
Laurence Field -
Maarten Litmaath -
Maarten.Litmaath＠cern.ch
-
Paul Millar -
Sergio Andreozzi