Messages in this thread | | | Date | Sun, 31 Jan 1999 18:24:02 +0000 | From | Jamie Lokier <> | Subject | Re: NFS causes mail loss and other nasties |
| |
John Goerzen wrote: >Now, here's what's interesting. I can do a ls -l of the mailbox, and it >will show up with a certain size on the server. On the client, it will show >up with a certain *SMALLER* size! (This would be the period of time between >when the new mail arrives and the client is aware of it).
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/
| |