Messages in this thread |  | | Subject | Re: 2.4.3-ac9/4 - NFS corruption | From | Trond Myklebust <> | Date | 02 May 2001 13:24:48 +0200 |
| |
>>>>> " " == Raphael Manfredi <Raphael_Manfredi@pobox.com> writes:
> Yes, mail is delivered on the server by mailagent, so with > proper local locking.
That's not good enough. The NFS client needs to know when it is in sync with the server...
> :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?
Yes. See the NFS-HOWTO for details.
> 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.
That can easily happen if the client thinks that the file is longer than it is on the server. A client has to rely on its cached value of the file length in order to append to a file, since it has to specify an offset at which to write. If that offset exceeds the current file length, the server does the equivalent of a truncate() to extend the file.
See RFC1094 and RFC1813 for further details on how NFS implements reading and writing...
Cheers, Trond - 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/
|  |