Message-ID: <01f801cec695$7e5d17e0$7b1747a0$@mindspring.com>
Date:	Fri, 11 Oct 2013 08:20:59 -0700
From:	"Frank Filz" <ffilzlnx@...dspring.com>
To:	"'Jeff Layton'" <jlayton@...hat.com>,
	<linux-fsdevel@...r.kernel.org>
Cc:	<linux-kernel@...r.kernel.org>,
	<nfs-ganesha-devel@...ts.sourceforge.net>,
	<samba-technical@...ts.samba.org>
Subject: RE: [RFC PATCH 0/5] locks: implement "filp-private" (aka UNPOSIX) locks

> > 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.

This is a good start.

I'd prefer a model where the private locks are maintained even if all file
descriptors are closed and released on garbage collection when the process
terminates. The model presented would require a server to potentially have
at least two file descriptors open (the descriptor originally used for the
locks, and a descriptor used for current access mode needed for some I/O
operation). The server will also need to "remember" to do all locks using
the first file descriptor.

Another thing that would be very useful for servers is to be able to specify
an arbitrary lock owner. Currently, Ganesha has to manage a union of all
locks held on a file and carefully pick it apart when a client does an
unlock. Allowing a process specified owner would allow Ganesha (or other
servers) to have separate locks for each client lock owner.

Frank

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists