[OpenAFS-devel] afs and byte-range locking ideas

[Craig_Everhart@transarc.com]

Excerpts from transarc.external.openafs: 5-Dec-01 Re: [OpenAFS-devel]
afs and.. Thomas Vincent@Pacbell.n (1261*)

> Does DFS take a huge performance hit due to its support of byte-level 
> locking?
> Or since DFS was designed from the ground up with byte-level locking in 
> mind, it doesn't take a hit. I realize DFS is a totally different beast 
> then AFS. It is the only file system with similiar capabilities to AFS 
> that supports byte-level locking that I can think of.

No, DFS doesn't take a huge perf hit for lock support or for maintaining
a data cache by range.  Though there are plenty of protocol
complications to support it, compared to AFS callbacks.  Instead of one
bit's worth of state for a callback, there are lots of token types
(represented as a bit mask), and both lock and data tokens have
associated byte ranges.  The concept of breaking a callback loosely
translates to revoking a token, and the token revocation exchange is
much trickier with byte ranges.  That is, if a client holds an
exclusive-lock token for byte range 100-500, a competing client might
ask for an exclusive lock for range 300-400.  The revocation message
from the server to the first client needs to say "please revoke your
100-500 token, using if you'd like the two subranges 100-299 and/or
401-500 instead".  The original client decides if it has any other way,
including the two ranges being offered, to cover the application's
current locks, and it responds appropriately (can't revoke, or revoke OK
accepting both tokens, or revoke OK accepting the first token, and so
on).

Management of data caching is comparable because of the byte ranges, but
in general data tokens are permitted to be revoked.  It's just that a
range-load data has to be stored back *before* allowing the last
write-data token (for the range) to be revoked.

		Craig