[Info-vax] CRTL and RMS vs SSIO

[Greg Tinkler]

> Well the perceived issue is what happens when taking out locks, and at 
> some point there is a conflict. Say needing 127 blocks locked, and the 
> conflict is on the last block. That means 126 locks to be released, and 
> perhaps try again. 
Maybe, maybe not.  It depends on the locking fan out factors for the differing levels.  It is possible that only 1 lock is needed, may be more, the wort case would be 127.  NB there is also BLAST to assist with managing the lock promotion/demotions.
 

> As long as storage is block oriented, then regardless of the numeric 
> range of bytes, all blocks encompassing the byte range will need to be 
> read, including locking, and written. This usually will include data 
> outside the byte range.

Yup, as is the case on Unix...let the drivers worry about how and why this is done, block/byte what ever the IO device needs.

> Forget RMS, I/O would be at the QIO level.

Why?  Underneath RMS is QIO, what RMS gives us the the coordination of the buffers/buckets/clumps/block across the cluster to ensure not lost updates, as per the example used to justify SSIO.

> RMS keyed files can have variable record lengths. 
True, VAR only not VFC or STM*, but fixed length key fields, with fixed offsets in the record

> RMS relative files require fixed length records. (if I remember correctly) 
Yup, there are implicitly fixed length.

===
Have been thinking about the byte range locking.  As most of the use will be for locking ranges in a file it should be integrated with RMS, i.e. RMS should have an API to allow this as it already does the locking to the buffer/bucket/clump/block.  Just need another 1 or 2 layers of lock tree and you have it.  And it all be cluster wide, and it will be compatible with other users of RMS.

gt