Re: dotfile locking, NFS and lockd
In article <[🔎] Pine.LNX.3.95.980304140113.5868A-100000@laranjada.that.com.br>,
Nelson Posse Lago <listas2@that.com.br> wrote:
>Hi,
>
>Quite some time ago (somewhere around debian 1.1 and 1.2), it was pointed
>out (by Miquel Smoorenburg, I think)
Yep.
>that while all debian programs
>(or all mail related programs?) agree in using dotfile locking, many of
>them used the "wrong" function to implement that, since the commonly used
>function is not atomic over NFS (meaning locking could fail over NFS on a
>busy machine).
Yes, using open("file", O_WRONLY|O_EXCL) is not atomic over NFS.
>So, I'd like to know the status of that; is this solved in 1.3.1? What
Not really.
>about 1.2 (I haven't upgraded yet, I'm lazy ;-) . Or, putting it
>differently: can I export my mail spool thru NFS and sleep at night if
>all systems involved run debian?
No, not by default. There is a way around it however; you can install
the libnfslock package. It's a preloaded library that intercepts the
open() call. If you use O_EXCL, it does an NFS safe file create using
a temp file and the link(2) system call.
We've been running with that for quite some time, and I haven't seen
any mailbox corruption yet even though me and my collegues read mail
over NFS every day..
>On the same line, I think the new (2.1.x) kernel-supported NFS server is
>supposed to have the hooks necessary to implement a really cool lockd for
>linux which would solve this kind of problem and allow for reliable NFS
>locking among linux and other Unixes etc.
Yes, but only if:
1. all programs use the same locking protocol (i.e. either safe dotfile
locking or fnctl() locking or both in the same order
2. The lockd's between different systems actually cooperate.
(1) means you need to inspect all programs anyway, and (2) means it
usually works in a homogenous environment. Not between different unixes
usually...
>Quite misteriously, I don't see
>mentions to this when people talk about the improvements of the new
>kernels, why is that? And is the lockd really being developed? If so,
Yes, lockd is indeed part of the new kernel nfsd, and there is client
side support in the 2.1.x NFS client code.
>should I expect it to be available when the newer kernel "freezes"?
The libnfslock solution is good enough for now, and when all programs
use the same locking protocol (which is dotlocking, or file based locking
according to the Debian policy) you can remove libnfslock from your
system. Note that it doesn't buy us much to move to fnctl() based locking
with the kernel lockd, since as I said the most difficult part is to
get all programs to just do locking in the same (safe) way, whether that
is dotlocking or fnctl() locking.
Mike.
--
Miquel van Smoorenburg |
miquels@cistron.nl | Luck is when preparation meets opportunity
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-user-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: