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

[Nathan Neulinger]

> 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?

Now I can see how a read on client2 might not get the data it had just
written if the file hadn't been closed. I suppose that's probably the
problem you're meaning. Perhaps write through would be a requirement if
multiple hosts have locks on the same file?

> > I guess what that implies is that the stage 1 (client side only
> > upgradable locks) are the best that we can do without completely
> > changing the way afs works. That would be an improvement - at least apps
> > on the same box can have fully functional locking support.
> 
> Without a significant protocol change, yes, stage 1 is the best we can do.

Even stage 1 only would be an improvement...