On Fri, Oct 11, 2013 at 08:25:17AM -0400, Jeff Layton wrote: > At LSF this year, there was a discussion about the "wishlist" for > userland file servers. One of the things brought up was the goofy and > problematic behavior of POSIX locks when a file is closed. Boaz started > a thread on it here: > > http://permalink.gmane.org/gmane.linux.file-systems/73364 > > Userland fileservers often need to maintain more than one open file > descriptor on a file. The POSIX spec says: > > "All locks associated with a file for a given process shall be removed > when a file descriptor for that file is closed by that process or the > process holding that file descriptor terminates." > > This is problematic since you can't close any file descriptor without > dropping all your POSIX locks. Most userland file servers therefore > end up opening the file with more access than is really necessary, and > keeping fd's open for longer than is necessary to work around this. > > This patchset is a first stab at an approach to address this problem by > adding two new l_type values -- F_RDLCKP and F_WRLCKP (the 'P' is short > for "private" -- I'm open to changing that if you have a better > mnemonic). > > For all intents and purposes these lock types act just like their > "non-P" counterpart. The difference is that they are only implicitly > released when the fd against which they were acquired is closed. As a > side effect, these locks cannot be merged with "non-P" locks since they > have different semantics on close. It isn't explicitly stated here, but will the POSIX and non-POSIX locks interact with each other? For example, if one process is using the old POSIX semantics for lock release, but another process is using the new non-POSIX semantics for lock release, will the two locks otherwise behave as expected and conflict with each other if needed? Cheers, Andreas > I've given this patchset some very basic smoke testing and it seems to > do the right thing, but it is still pretty rough. If this looks > reasonable I'll plan to do some documentation updates and will take a > stab at trying to get these new lock types added to the POSIX spec (as > HCH recommended). > > At this point, my main questions are: > > 1) does this look useful, particularly for fileserver implementors? > > 2) does this look OK API-wise? We could consider different "cmd" values > or even different syscalls, but I figured this makes it clearer that > "P" and "non-P" locks will still conflict with one another. Cheers, Andreas -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
