lkml.org 
[lkml]   [1999]   [Feb]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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).

Enjoy,
-- Jamie

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

\
 
 \ /
  Last update: 2005-03-22 13:50    [from the cache]
©2003-2011 Jasper Spaans