SourceForge : Post

Project: Editor Discussion > REC: Usage Record - XML Fmt > Disk != storage > List of Posts

Forum Topic - Disk != storage: (3 Items)

View: as

08/11/2004 2:31 PM

post4314

Disk != storage

Under 7.2, "disk" seems to be used synonymously with "long-term storage."  I would change the label to something more 
representative.

For example, I might have storage on optical media, tape media, or solid state media.  These are not disk, but 
presumably would fall under the same "persistent" rubrick.

This has implications for work v. permanent storage, too.

Scott Jackson

02/22/2005 8:15 PM

post4315

RE: Disk != storage

This issue was discussed and it was felt that Disk was sufficient for use as a common usage property because it is the 
term that is predominantly used by contemporary systems. 

So currently, you could use something like:
<Disk description="Tape" units="MB">1213</Disk>
if the use of the word Disk in this instance is not too objectionable.

It was also for reasons like this that the ConsumableResource property was included in the specification although it 
currently lacks a type attribute necessary to be used in this manner. It is my hope to remedy this omission so that you 
could express your various storage types something like:

<ConsumableResource type="Storage" description="Tape" units="MB">1213</ConsumableResource>

You raise a good point, however, and I would like to see this issue debated in more depth before the next version of the
 specification is released.

bernie baillargeon

02/23/2005 2:40 PM

post4316

transactional, message domains, speed, etc.

I also believe the concept is more properly abstracted, for other reasons as well.   As most references to "disk" that I
 read are really to "persistent store", the thin-thread of disk's definition may mask implications.  As noted, off-CPU 
storage can be optical, tape, chip or disk, yet may also include within contexts, the caches- on chip cache, L2 cache, 
memory cache and disk array cache.  Ooops- there was that word again.  So speed of off-CPU storage may very well be an 
important factor- tape and optical being slow, disk med-high, caches from med-high to high, and memory at the highest 
speeds.  
Also the app domain of either a state-management / messaging domain versus a transactional domain apply differing 
requirements on the infrastructure storage- one relies heavily upon cache and fast-access storage, the latter more 
heavily on the common 'disk' storage.  I'm not an expert but have seen some recent discussions related to the often 
missed  variances these two domains display in an operational aspect.  Operational aspects are key to grid/ service 
infrastructure, so I thought I would mention it.  If I can glom a copy of the discussions I refer to I'll paste their 
URLs here.

Return