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

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