lkml.org 
[lkml]   [2013]   [Dec]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [Nfs-ganesha-devel] [PATCH v3 0/6] locks: implement "filp-private" (aka UNPOSIX) locks
Date
> This patchset is the third posting of this set. Behavior between this set
and
> the last should be more or less the same. Here is a summary of
> changes:
>
> v3:
> - more consolidation of common code between flock_to_posix_lock and
> flock_to_posix_lock64
> - better bisectability by reordering changes, such that partial
> implementation won't be exposed
> - s/filp/file/ s/FILP/FILE/ in symbol names
>
> v2:
> - 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:
>
> http://austingroupbugs.net/view.php?id=768
>
> 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
me
> as to the status of this work. There seems to be a lot of interest since
classic
> 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.

Thanks

Frank

> Original cover letter from v1 posting follows. Comments and suggestions
> welcome.
>
> -------------------------------[snip]------------------------------
>
> 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.
>
> 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.
>
> 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
> handlers
> 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(-)
>
> --
> 1.8.4.2
>
>
>
----------------------------------------------------------------------------
--
> 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
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clk
> trk
> _______________________________________________
> Nfs-ganesha-devel mailing list
> Nfs-ganesha-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel



\
 
 \ /
  Last update: 2013-12-12 13:41    [W:0.115 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site