[lkml]   [1999]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [nfs - lockd] mutt / elm
Thierry Danis wrote:
> Moreover, we are using 'procmail' to redirect mail messages
> in home-based folders (ie, NFS folders), and are no longer
> using NFS mounted /var/spool/mail directory. We need to have
> some kind of locking mechanism for other utilities on our
> home NFS directories, so we can not anyway use 'nolock' to
> automount them (right ?).

"nolock" only turns of fcntl()/lockf()-style remote locking.
Local locking still works, as does flock() which is _always_ local-only.
(So never use flock() on Linux for a mail folder).

Mail programs like Mutt and Elm use another kind of locking for mail
folders in addition to fcntl(): dot-locking. This involves creating
additional empty files. When done properly, the _locks_ sequence
properly over NFS, but Linux may still cache stale contents of the
_mailbox_ itself. "actimeo=0" fixes the latter problem.

> My feeling is that it would be better to fix the locking
> approach of mutt. Elm failed to work also with the new 2.2.x
> kernels : I did recompile it (it checks which locking method it
> can use during its configuration). But I have still one
> problem with elm : I tried to recompile elm-ME+ (with MIME
> support), and it fails during folder resynchronisation (at
> least it did fail with 2.2.0-pre7ac4).
> The symptom of the failure are as follows :
> MBOX is my NFS folder
> TMP is a working copy of MBOX in /tmp
> 1 fopen(MBOX)
> 2 unlink(MBOX) : MBOX is still visible (from the Linux box)
> 3 ftruncate(MBOX)
> 4 fread(TMP, Buffer) & fwrite(MBOX, Buffer) (<=> copy TMP in MBOX)
> Up to now, MBOX is still visible from the Linux box
> 5 fflush(MBOX)
> 6 <a few seconds later> : MBOX has disappeared
> 7 elm-ME+ does not like to have lost MBOX ;-( (and I do not either)

Yes it's cache problems. Solution: "actimeo=0" mount option fixes this
too. Performance penalty (more network traffic), which is why I prefer
to use fcntl() locking and have a working rpc.lockd at both ends.

> It is working nice with the 2.0.x kernel serie. Maybe a(nother ?)
> cache problem with the new NFS layer ?

It is working nice (no errors), but probably losing mail from time to
time. The test is:

> It's easily tested. This is what I did with Mutt (should be similar
> with Elm, Pine etc.):
> 1. Send myself a mail. Wait at least 60 seconds.
> 2. Start Mutt, see the mail with "N" flag.
> 3. Read mail, clears "N" flag.
> 4. Send myself a mail from within Mutt.
> 5. Synchronise mail folder ("$" key).
> 6. See that the second mail has got lost.
> 7. Repeat until convinced.
> Extra steps include:
> 4a. Read mail on another machine, prove that the second mail did arrive.
> 6a. See that the second mail isn't visible on the other machine either.
> 8. Fix kernel (see below).

-- Jamie

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.033 / U:0.312 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site