[Info-vax] Byte range locking - was Re: Oracle on VMS

[David Froble]

Robert A. Brooks wrote:
> On 11/21/2016 11:27 PM, David Froble wrote:
>> Robert A. Brooks wrote:
>>> On 11/21/2016 9:47 PM, Craig A. Berry wrote:
>>>> <discussion of SSIO and byte range locking snipped>
>>>
>>>> SSIO involves a pretty complex interaction among RMS, the XQP,
>>>> the CRTL, and XFC, so there are a lot of things that could go
>>>> wrong. I believe VSI looked at it long enough to say "we're not
>>>> doing that right now" but they've kept it on their list of
>>>> research projects.
>>>
>>> Unless a customer shovels a lot of money our way, SSIO won't get
>>> any attention until after X86 ships.
>>>
>>> I *think* that what shipped as part of the SSIO project was a very
>>> limited prototype that was limited to a single node with no cluster
>>> wide locking semantics, so it's not a surprise if something
>>> fundamental is not fully implemented.
>>>
>>
>> From the little reading I've done, I see several things that either
>> puzzle me, disgust me, or both.
>>
>> SSIO appears to be something that is for C, not for VMS.  I'd think
>> that if such work was to be done, it would be for VMS, usable by any
>> languages on VMS.
> 
> It was done primarily for Unix/Linux portability, where the vast majority
> of stuff was written in C.  That's not as true now as it was a decade ago,
> however.
> 
>> It appears I cannot find my Internals and data structures book.  Not
>> sure how helpful it would have been.  What I've never thought about
>> before, and now seems to me to be a central aspect of this entire
>> issue, is how VMS handles updates on disk of pieces of data smaller
>> than the disk cluster size.  For example, disk cluster size of 8, and
>> reading and updating one block.
> 
> You have a (common) misconception regarding I/O and disk cluster factors.
> 
> Disk cluster factors are used for storage allocation bitmaps only.  I/O is
> done at the byte level.  If you want to write seven bytes, we'll only write
> seven bytes.   For fun, play around with the DKDRIVER DKLOG SDA 
> extension, to
> see what the SCSI disk class driver does with I/O requests.  You'll learn
> a lot about UCBs, IRPs, etc . . .
> 
>> Is there any material that describes this capability?
> 
> Other than whatever was distributed with the SSIO prototype, probably not.
> I wasn't in VMS Engineering when SSIO was released.
> 
>> Is there anyone at VSI that is knowledgeable, and willing to discuss the
>> capability.
> 
> I'll check; most of the folks that did SSIO are not at VSI.
> 

Ok, likely I'm missing something, but let me ask, what's so difficult?

Get a request for a string of bytes that for example spans disk blocks 2367 to 
2714, with the first and last blocks possibly (likely) only partly required.  So 
what?  Get locks for all the blocks, allocate a buffer, read the range of 
blocks, possibly make changes, and write the buffer back to disk.  If cache is 
in use, it should just work.  Yes, that's a lot of locks to successfully 
acquire.  But no mods to the DLM.

The database I implemented back in 1984 uses a similar technique for up to 127 
contiguous blocks.  Granted, large buffers are rarely used, most often just one 
512 byte block.  Ummm ... actually, the keys are set up in 4 block chunks.

If the choice is a product with locking overhead, or no product, which is better?

Note, I have no idea if reads and writes of hundreds of blocks is normal ...