Messages in this thread |  | | From | (Raphael Manfredi) | Subject | Re: 2.4.3-ac9/4 - NFS corruption | Date | 2 May 2001 04:29:41 GMT |
| |
Quoting Trond Myklebust <trond.myklebust@fys.uio.no> from ml.linux.kernel: :>>>>> " " == Raphael Manfredi <ram@ram.fr.eu.org> writes: : > An "ls -l" on the file yields: : : > -rw------- 1 ram users 1642491 May 1 00:00 inbox : : > (on the server, and via NFS), which is *abnormal*, since it's : > 15:18 and I've just updated the file. Therfore, the timestamp : > is corrupted as well in the inode. : :In that case you have some other task that has done a 'touch' or :something to the file. An NFS client does not explicitly set the :timestamp when doing ordinary reading/writing to a file - it leaves it :to the server to do so.
Of course, I understand that. It's *abnormal* because I told "mutt" to delete a message from the mailbox, and then re-synchronized it, thereby writing to it. I expected the timestamp to be updated on the server after that operation. It did not happen.
:Would you happen to be delivering mail to the same file on the server :or something like that?
Yes, mail is delivered on the server by mailagent, so with proper local locking.
:If so it's completely normal behaviour: the userland NFS doesn't :support file locking, so there's no way that the client can guarantee :that some task on the server won't write to the file behind its :back...
Does kernel-land NFS support file locking?
In any case, "mutt" does not lock the file, so yes, I'm perfectly aware there could be a race. But not the kind of race that would NULL-ify 5 bytes on the file when read from the client, whilst those same bytes are perfectly normal when read from the server.
Raphael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |