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

[Jeffrey Hutzelman]

On Mon, 3 Dec 2001, Nathan Neulinger wrote:

> > 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.
> 
> So what you're saying is - with the way afs is designed, multiple
> clients can NEVER safely modify a file simultaneously, even if those
> clients are accessing completely separate ranges of the file? So even if
> the one client only sent a single block worth of writes to the file on
> the server, that cannot be relied upon by other clients?

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