lkml.org 
[lkml]   [2001]   [May]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.4.3-ac9/4 - NFS corruption
From
Date
>>>>> " " == 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/

\
 
 \ /
  Last update: 2005-03-22 12:52    [W:0.076 / U:6.308 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site