This problem can actually lose your mail, if the client reads the
smaller mailbox and writes it back (e.g. to delete a message). You used
to have about 30 seconds during which this could happen -- very bad.
Miquel van Smoorenburg wrote:
> *Always* mount your mail spool with the "noac" option (No Attribute
> CAching)
The problem was noticed a while back, and fixed in 2.1.131. The file
shows up with a smaller size due to attribute cacheing, but now when
your mail client locks the file using fcntl(F_SETLK), the cache is
flushed and it will see the new data.
So, *if* your mail client use fcntl() to lock the mailbox, in addition
to any other locking it uses, "noac" (can be written "actimeo=0") isn't
necessary since 2.1.131. I know my mail client does this, but does
yours?
There are still a rare condition w.r.t. overlapping I/O requests
revalidating the cache prematurely. However the loss window for this is
_much_ smaller (millisecond or so), and even then quite rare. It will
be closed in a future kernel.
Miquel's assertion is good advice. But technically, if you _know_ your
mail client calls fcntl() for locking, and you haven't mounted with
"nolock", it is safe to mount your mail spool with the default attribute
cacheing options. The no-"nolock" restriction will be lifted in future.
-- 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/