[Info-vax] Byte range locking

John E. Malmberg wb8tyw at qsl.net_work
Tue Nov 22 13:02:06 EST 2016


On 11/22/2016 10:50 AM, David Froble wrote:
>
> 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.

RMS can only take out locks for existing blocks.

Many of the fcntl()/flock() requests are for byte ranges that do not exist.

Also many of the files are stream or an undefined record format, so no 
record IDs to use.

With out using RMS locks, the application needs SYSLCK to use the DLM.

Now setting up byte rangs locks has a lot of overhead, so some platorms 
have implemented Opportunistic locking.

The simple explanation for them is that the lock request first attempts 
to do an exclusive lock on the file.  If it can get that, it just tracks 
the byte-range locks internally, but does not actually take them out.

If no other application ever tries to lock that file, then a lot of 
overhead is skipped.

When a second application tries to take out a byte-range lock, the first 
application is notified and it then takes out the byte-range locks and 
releases the exclusive lock.  This is a lot of overhead as buffers need 
to be flushed and distributed caches may be involved on served files.

I do not know if I can use a user written blocking AST with an RMS 
granted lock.  If I could do that, then it should be possible to write 
an byte range locking simulation what would work completely in user mode 
code.

Regards,
-John
wb8tyw at qsl.net_work





More information about the Info-vax mailing list