Date: Sun, 8 Dec 2002 18:59:30 -0500 From: Chris BeHanna <chris@pennasoft.com> To: current@freebsd.org Subject: NFS Locking Problems (Was: Re: I'm impressed, but ...) Message-ID: <200212081859.30520.chris@pennasoft.com> In-Reply-To: <20021207224048.GG27267@juno.home.paeps.cx> References: <20021125004934.GA604@juno.home.paeps.cx> <20021207221018.GA373@raggedclown.net> <20021207224048.GG27267@juno.home.paeps.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
On Saturday 07 December 2002 05:40 pm, Philip Paeps wrote:
> On 2002-12-07 23:10:18 (+0100), Cliff Sarginson <cls@raggedclown.net> wrote:
> > On Sat, Dec 07, 2002 at 08:41:35PM +0100, Philip Paeps wrote:
> > > On 2002-11-25 01:49:34 (+0100), Philip Paeps <philip@paeps.cx> wrote:
> > > Perhaps someone can make sense of this? I'm happy I can read my mail
> > > now, without having to kick the power button every so often, but I'd
> > > prefer to store my mail here and have the mailserver write over NFS.
> > > (Mainly for speed reasons).
> >
> > I suspect file locks across NFS as a possible source of this kind of
> > problem.
>
> Locking is always a problem over NFS :-/ It's one of the reasons I'm using
> maildirs instead of normal happy mboxes.
You could use IMAP instead, allowing you to read and sort your
mail from anywhere. Mutt is capable of IMAP, no?
> Theoretically - correct me if I'm wrong - file locks shouldn't matter with
> maildirs as once a file is written, there's not much chance of it having to
> be written again, let alone by more than one process?
This is up to the processes that have opened the files. File
locks over NFS are obtained by userland programs via the fcntl(2)
system call, and it's quite likely (and desired, in fact) that mutt is
obtaining, at the least, read locks on the files that it has opened.
> How would one verify that NFS locking is causing pain? There's some NFS
> debugging stuff in NOTES... I'm willing to try anything to help fix this
> :-)
A pair of simple test programs works well. One file creates a
file, opens it, and locks it. The other program attempts to obtain
either conflicting (e.g., try to grab a write-lock while the other
process has a read-lock) or non-conflicting locks (try to grab a
read-lock while the other process has a read-lock).
It is best to run the programs on different hosts, against the
same NFS filesystem. I've discovered that fcntl(2) on 4.x systems
misbehaves in that the client host keeps track of the locks, so that
different programs on the same client host (say, host A) honor the
locks, but the lock is not propagated to the NFS server; therefore,
processes on other hosts are not restrained by the locks that have
been acquired by processes on host A. I have not tried these tests on
current.
To be fair, I only recently read (here) that rpc.lockd has to
run on the client side as well as on the server side, and I have
not yet repeated my tests. That's on my List of Things to Do RSN.
--
Chris BeHanna http://www.pennasoft.com
Principal Consultant
PennaSoft Corporation
chris@pennasoft.com
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200212081859.30520.chris>