I'm trying to figure out this code to where I can look at having a try at clientside byte-range locking. Would appreciate any comments from others more in tune with kernel internals... Some of this is very stream of thought, so please excuse the babbling.
So far, since everything is based in terms of flock, and flock doesn't do byte ranges at all, looks like I'll need to basically scrap the whole lot and rework from scratch - basically in reverse, doing more like fcntl, but generalized. In some respects, that seems a bit easier. A place I'm not really clear on - in afs_xflock, it looks like a mix of afs doing it's own lock tracking, as well as updating fields in the kernel file descriptor recording lock states, and calling flock() if !flockDone. Why would the lock not have been done? It looks like getf() is returning a kernel file handle of some sort, and f_flag in that is being used to keep track of whether any exclusive or shared lock exists on the file. (Not sure what purpose that serves.) With brlocks, the potential exists for ranges of the file to be locked for read, and independent ranges to be locked for write at the same time, seems to me that the only way this will be managed is for the lock on the server to be the most upgraded version - i.e. if there are only read locks in place, would be sufficient to have a single read lock on server, but the moment a write lock is needed, the server lock would have to be upgraded to a write lock. In an of itself, this doesn't seem like a big problem - the code already has examples of lock upgrades. There are a number of references to avc->flockCount, these obviously would no longer be meaningful, as the semantics will have changed. (Could possibly have both readers and writers at same time.) I'd presume on perhaps changing it's meaning to just a count of locks on the file, both R+RW. Is the number in ObtainWriteLock for src purely an arbitrary one - i.e. just try to keep unique throughout code for debugging purposes? Are there are special restrictions on use of osi_AllocSmallSpace? Looks like it's already used in this case to build the SimpleLocks linked list. Should that avoid allocating very much memory? or is it just meant for allocating a small piece of memory (as opposed to a large piece at a time). Looks like I should actually be able to use the SimpleLocks structure with only minor changes. It seems like there is a race condition in the locking protocol with the server - to do a lock upgrade, it releases the lock, and then requests a new one. Don't know if that has much impact, seems like it could be dangerous if you attempt to upgrade a R to an RW while there are other processes/clients waiting on an RW at the same time. Any comments, especially "You're heading off in the completely wrong direction" ones, would be appreciated. Other than some of the kernel issues I'm not sure about, I think I've got a pretty clear picture in my head of how I'll work this, and it should actually simplify things a bit. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
