On Mon, 3 Dec 2001, Nathan Neulinger wrote: > Stage 2: Add support for block range locks to the file servers. > Added RPC: GetSmallestLockSize > Added RPC: LockRange(... size ...) > > This will build upon the support in stage 1. Basically, when the client > receives a request for a byte range lock, before immediately upgrading > it to a full-file lock, it should ask the server "what size locks do you > support". If the server supports smaller locks than whole-file, then > request the minimal lock needed. > > NOTE - The minimum lock size requestable by the client should be no > smaller than the minimum update-size sent to the server. (i.e. if the > client sends a whole block to the server when the process updates a > single byte, then it should request a lock no smaller than the block, > regardless of what the server supports.) > > This should still retain full support for all clients, other clients > will continue to request full-file locks, which would be granted or not > as usual. > > Gain: Better granularity, assuming just block locking, multiple clients > could start doing byte-range locks, so long as they were in different > blocks of the file.
Unfortunately, you're not only glossing over all the problems with having the server keep lock state (most of which are not insurmountable); you're also missing a fundamental problem. If you allow multiple hosts to hold byte-range locks at the same time, then applications on those hosts will try to write the file at the same time. The result will be a mess, since the applications think they have locked the parts of the file they're updating but the whole-file last-write semantics of AFS mean they really don't. -- Jeffrey T. Hutzelman (N3NHS) <[EMAIL PROTECTED]> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
