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

[Jeffrey Hutzelman]

On Wed, 5 Dec 2001, Nathan Neulinger wrote:

> > Not with the current protocol.  That sort of capability would require
> > block-level callbacks and data version tracking, which could quickly get
> > messy.  I'm not saying its impossible, but it would require considerable
> > additional work, and might turn out to impact performance too much.
> 
> I guess the thing I don't understand is - why does it matter what the
> cache says?
> 
> i.e. client 1 and 2 open file, client 1 sends changes to server and
> closes. At this point, the cache is invalid on client 2, but the
> application on client 2 then sends a block of changes to the server. 
> 
> Is the result not predictable at that point? I don't see why it wouldn't
> be. Why does client 2 care what's in the cache if it's just sending a
> write?

The problem here is that client 2 can't send an update unless its copy of
the data is valid.  This is required for consistency.  It _might_ work; 
I'd have to read the code, and I don't have time at the moment to reabsorb
the cache manager code to the point where I could say for certain.  But
even if it does work, it will be slow -- if clients 1 and 2 are both using
the file, then each time one of them writes, the other will have to
refetch the entire file. 

This is made less of a problem by the normal semantics of not flushing any
writes to the fileserver until the file is closed.  But that plays havoc
with your byte-range locking, since you can't safely release a lock until
the relevant data has been written.  More precisely, you can't safely
release a lock until _all_ the data written to the file while the lock was
held has been sent back to the fileserver, even if the data wasn't in the
region covered by the lock -- many applications have complex locking
models where a lock on one data structure also covers related structures.

> Even stage 1 only would be an improvement...

Yes, I think it would be an improvement in many cases.  It should probably
be something that can be turned on and off by an admin.  I suggest you
submit a patch.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA