2.4.3-ac9/4 - NFS corruption

2.4.3-ac9/4 - NFS corruption

[Raphael Manfredi]

My NFS client runs 2.4.3-ac4 (SMP).
My NFS server uses user-land NFS and runs 2.4.3-ac9 (UP).

I've seens the following in my ~/mail/inbox, NFS mounted:

	^@^@^@^@^@^@est-admin@lists.sourceforge.net  Tue May  1 14:47:02 2001

On the server, the same line reads:

	From test-admin@lists.sourceforge.net  Tue May  1 14:47:02 2001

The above "^@" are NULL bytes, as displayed by "vi".
The data around those NULL bytes were perfect, i.e. there was text before
in the mailbox that was correct.

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.

If I create a file, via "> ~/mail/test" on NFS, it reads:

	-rw-r--r--    1 ram      users           0 May  1 15:19 test

with a proper timestamp.

The NFS access is done via a symlink to an NFS-mounted dir, i.e. ~/mail
is actually a symlink to /nfs/lyon/home/ram/mail.

Any hint as to what is happening?  Is that a known problem?

Raphael

Re: 2.4.3-ac9/4 - NFS corruption

[Trond Myklebust]

>>>>> " " == Raphael Manfredi <ram@ram.fr.eu.org> writes:

     > My NFS client runs 2.4.3-ac4 (SMP).  My NFS server uses
     > user-land NFS and runs 2.4.3-ac9 (UP).

     > I've seens the following in my ~/mail/inbox, NFS mounted:

     > 	^@^@^@^@^@^@est-admin@lists.sourceforge.net Tue May 1 14:47:02
     > 	2001

     > On the server, the same line reads:

     > 	From test-admin@lists.sourceforge.net Tue May 1 14:47:02 2001

     > The above "^@" are NULL bytes, as displayed by "vi".  The data
     > around those NULL bytes were perfect, i.e. there was text
     > before in the mailbox that was correct.

     > 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.

     > If I create a file, via "> ~/mail/test" on NFS, it reads:

     > 	-rw-r--r-- 1 ram users 0 May 1 15:19 test

     > with a proper timestamp.

     > The NFS access is done via a symlink to an NFS-mounted dir,
     > i.e. ~/mail is actually a symlink to /nfs/lyon/home/ram/mail.

     > Any hint as to what is happening?  Is that a known problem?

Would you happen to be delivering mail to the same file on the server
or something like that?
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...

Cheers,
  Trond

Re: 2.4.3-ac9/4 - NFS corruption

[Raphael Manfredi]

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

Re: 2.4.3-ac9/4 - NFS corruption

[Trond Myklebust]

>>>>> " " == 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