[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.023 / U:51.968 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site