[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAKgNAkgv5NqDRUNu0XtSABqmctd7=rpMMEYhhDQNzPssZuU5bA@mail.gmail.com>
Date: Sun, 27 Apr 2014 13:11:33 +0200
From: "Michael Kerrisk (man-pages)" <mtk.manpages@...il.com>
To: NeilBrown <neilb@...e.de>
Cc: "Stefan (metze) Metzmacher" <metze@...ba.org>,
Jeff Layton <jlayton@...hat.com>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
lkml <linux-kernel@...r.kernel.org>,
Ganesha NFS List <nfs-ganesha-devel@...ts.sourceforge.net>,
Suresh Jayaraman <sjayaraman@...e.de>,
Trond Myklebust <trond.myklebust@....uio.no>,
Christoph Hellwig <hch@...radead.org>,
linux-nfs <linux-nfs@...r.kernel.org>,
"J. Bruce Fields" <bfields@...ldses.org>
Subject: Re: flock() and NFS [Was: Re: [PATCH] locks: rename file-private
locks to file-description locks]
On Sun, Apr 27, 2014 at 12:04 PM, NeilBrown <neilb@...e.de> wrote:
> On Sun, 27 Apr 2014 11:16:02 +0200 "Michael Kerrisk (man-pages)"
> <mtk.manpages@...il.com> wrote:
>
>> [Trimming some folk from CC, and adding various NFS people]
>>
>> On 04/27/2014 06:51 AM, NeilBrown wrote:
>>
>> [...]
>>
>> > Note to Michael: The text
>> > flock() does not lock files over NFS.
>> > in flock(2) is no longer accurate. The reality is ... complex.
>> > See nfs(5), and search for "local_lock".
>>
>> Ahhh -- I see:
>> http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=5eebde23223aeb0ad2d9e3be6590ff8bbfab0fc2
>>
>> Thanks for the heads up.
>>
>> Just in general, it would be great if the flock(2) and fcntl(2) man pages
>> contained correct details for NFS, of course. So, for example, if there
>> are any current gotchas for NFS and fcntl() byte-range locking, I'd like
>> to add those to the fcntl(2) man page.
>
> The only peculiarities I can think of are:
> - With NFS, locking or unlocking a region forces a flush of any cached data
> for that file (or maybe for the region of the file). I'm not sure if this
> is worth mentioning.
I agree that it's probably not necessary to mention.
> - With NFSv4 the client can lose a lock if it is out of contact with the
> server for a period of time. When this happens, any IO to the file by a
> process which "thinks" it holds a lock will fail until that process closes
> and re-opens the file.
> This behaviour is since 3.12. Prior to that the client might lose and
> regain the lock without ever knowing thus potentially risking corruption
> (but only if client and server lost contact for an extended period).
Do you have a pointer for that commit to 3.12?
>> Anyway, returning to your point about flock(), how would this text
>> look for the flock(2) manual page:
>>
>> NOTES
>> Since kernel 2.0, flock() is implemented as a system call in
>> its own right rather than being emulated in the GNU C library
>> as a call to fcntl(2). This yields classical BSD semantics:
>> there is no interaction between the types of lock placed by
>> flock() and fcntl(2), and flock() does not detect deadlock.
>> (Note, however, that on some modern BSDs, flock() and fcntl(2)
>> locks do interact with one another.)
>>
>> In Linux kernels up to 2.6.11, flock() does not lock files over
>> NFS (i.e., the scope of locks was limited to the local system).
>> Instead, one could use fcntl(2) byte-range locking, which does
>> work over NFS, given a sufficiently recent version of Linux and
>> a server which supports locking. Since Linux 2.6.12, NFS
>> clients support flock() locks by emulating them as byte-range
>> locks on the entire file. This means that fcntl(2) and flock()
>> locks do interact with one another over NFS. Since Linux
>> 2.6.37, the kernel supports a compatibility mode that allows
>> flock() locks (and also fcntl(2) byte region locks) to be
>> treated as local; see the discussion of the local_lock option
>> in nfs(5).
>> ?
>
> That seems to cover it quite well - thanks.
Thanks for checking it.
Cheers,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
--
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