[Nfs-ganesha-devel] [PATCH v3 0/6] locks: implement "filp-private" (aka UNPOSIX) locks
ffilzlnx at mindspring.com
Tue Dec 10 12:30:54 MST 2013
> This patchset is the third posting of this set. Behavior between this set
> the last should be more or less the same. Here is a summary of
> - more consolidation of common code between flock_to_posix_lock and
> - better bisectability by reordering changes, such that partial
> implementation won't be exposed
> - s/filp/file/ s/FILP/FILE/ in symbol names
> - inheritance semantics have been change to be more BSD-lock like
> - patchset size has been reduced by changing how lock ownership
> is handled
> - new F_UNLCKP l_type value has been added
> Note too that I've gone ahead and opened a request for the POSIX folks to
> consider adding this to the POSIX spec once we have something mergeable.
> They seem amenable to the idea but don't want to enshrine it into the
> standard until there's a real implementation of it:
> I also owe them a better writeup of the semantics for these new locks, but
> have been holding off on doing that until they're a little more settled.
> As a side note, I've also had a few other userland developers reach out to
> as to the status of this work. There seems to be a lot of interest since
> POSIX locks are such a pain to work with in threaded programs. Hopefully
> some will chime in on this posting...
This is looking really good to me. I will be excited to utilize this
capability in Ganesha.
> Original cover letter from v1 posting follows. Comments and suggestions
> At LSF this year, there was a discussion about the "wishlist" for userland
> 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
> 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
> file descriptor for that file is closed by that process or the process
> that file descriptor terminates."
> This is problematic since you can't close any file descriptor without
> all your POSIX locks. Most userland file servers therefore end up opening
> 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
> 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
> fd against which they were acquired is closed. As a side effect, these
> cannot be merged with "non-P" locks since they have different semantics on
> I've given this patchset some very basic smoke testing and it seems to do
> 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.
> Jeff Layton (6):
> locks: consolidate common code in the flock_to_posix_lock routines
> locks: consolidate checks for compatible filp->f_mode values in setlk
> locks: rename locks_remove_flock to locks_remove_file
> locks: show private lock types in /proc/locks
> locks: report l_pid as -1 for FL_FILE_PVT locks
> locks: add new "private" lock type that is owned by the filp
> fs/file_table.c | 2 +-
> fs/locks.c | 122
> include/linux/fs.h | 5 +-
> include/uapi/asm-generic/fcntl.h | 16 +++++
> 4 files changed, 85 insertions(+), 60 deletions(-)
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel at lists.sourceforge.net
More information about the samba-technical