[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