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

[David Froble]

BillPedersen wrote:
> On Sunday, November 20, 2016 at 11:21:11 PM UTC-5, David Froble wrote:
>> BillPedersen wrote:
>>
>>> Well we do not yet have Postgres on VMS.  There are a couple stumbling points
>>> that have gotten in the way.  Shared Stream IO to files to allow multiple
>>> writers and byte-range locking in the same context as the SSIO.  There are
>>> two features  which several "data" sharing applications running on Linux/Unix
>>> quite often have in common and they are the biggest stumbling points of
>>> getting these sorts of software to run on VMS effectively.
>> I guess my first question is, how does *ix do byte range locking?  There is 
>> nothing special about locking between cooperating tasks.  Just needs a good 
>> design, and then implementation.  With the initial help of John Santos I've 
>> implemented a locking system.
>>
>> The reason I've asked how *ix does the job is that it's my impression that to do 
>> other than agreed upon fixed length data locks, it seems that otherwise would 
>> have to know a bit more about the data.  That's a bit different from what I've 
>> done in the past, and how the VMS DLM works.
>>
>> Got any specifications?
> 
> The API is via either fcntl() of flock() depending on the flavor of the day.

Bill, you must not get out much, I thought everyone knew that I don't do C, I 
don't think of C, and if I trip over it I kick it.

:-)

> Issue with these and Samba is that fcntl() limits the range to 2^31 bytes, according to some documents I have read while Windows clients can request up to 
> 2^32 or 2^64 bytes depending on the client.  So Samba has some other their own internal locking that I have to explore.

Yeah, I actually have started to think about this "thing", and if you're really 
using individual bytes as the lowest unit of measure, then the numbers used are 
going to get rather large.  Regardless if you actually convert to block numbers, 
the byte IDs will require very large integers.

> But without a coordinated cache then that might not help much.  Since since
> shared stream IO allows updating of non-overlapping regions in a block...

Well, as I understand it, today's disks can have a minimum cluster size of maybe 
8 blocks, but, while I'm not familiar how VMS does it, you can still read, and 
update, individual 512 byte blocks.  VMS has always had to work with disk 
cluster size.  I'm thinking that I need to get some understanding of how this is 
implemented.  Possibly the same technique could be used for updates not on disk 
block boundaries?

This is starting to grab my attention.  Maybe I should be afraid?