[OpenAFS-devel] protocol change requests and update on byte range locking - where to discuss?

[Nathan Neulinger]

I'd like to request a new fileserver opcode for lock upgrades. I'm
starting to dig into the byte range locking stuff I talked about doing,
and one of the pieces of that is adding a reasonable lock upgrade
mechanism, as opposed to the current it's-always-a-race-condition
approach of dropping the lock and re-acquiring.

Where does this need to be discussed or is there a forum for the
protocol at the moment?

For reference, here's my plan on the locking code -
	Instrumenting the current kernel code that does locks to where I can at
least see the what data the kernel is getting passed for the various
test scripts I've written.

	Attempt to come up with a consolidated lock routine that duplicates
existing functionality but cleanly supports both fcntl and flock for
whole file ranges without having to distinguish between them in the
kernel code.

	Implement the kernel data structure for tracking the overlapping byte
range requests, but don't actually do the locking yet.

	Start actually attempting to do locking without being concerned about
overlaps between multiple processes - just get the 'lock a range, but
upgrade to fileserver' part working.

	Handle overlapping ranges.
	
	Cleanly handle a lock upgrade when you already have read range-locks
and you ask for a write range-lock. This one concerns me a bit. It will
be implementable with current file servers, but it's a race since the
current code will require dropping the server lock when the client still
thinks it has it. Current code already does this so my inclination is
"These locks won't be completely safe unless you have current file
servers." Since they are completely unsafe currently, that seems
reasonable to me.

I'm planning on implementing for unix clients. I know there is interest
on the windows side as well, it should be directly translatable.

As mentioned previously, this support will span a single client only.
Other clients will see that the entire file has been locked. This is the
only mechanism possible without major protocol and cache coherency
changes. 

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216