I see exactly the same thing with an SGI Irix 6.2 (or 5.3) client
and a Linux 2.1.78 (+ your dcheck/nfs patches) server.
A Linux 2.0.33 client works ok.
% echo xxx > xxx
% echo yyyyyyyy > yyyyyyyy
% ls -l
-rw-r--r-- 1 richter agluger 4 Jan 8 14:08 xxx
-rw-r--r-- 1 richter agluger 9 Jan 8 14:08 yyyyyyyy
% cp xxx yyyyyyyy
% echo q > yyyyyyyy
% ls -l yyyyyyyy
-rw-r--r-- 1 richter agluger 9 Jan 8 14:09 yyyyyyyy
% cat yyyyyyyy
q
x
yyyy
> A couple of questions ... if you check the file yyyyyyyy on the Linux
> server, does it have the correct contents? From the output it looks as
> though the OS-9 client may not have flushed its caches -- note that the
> file length seems correct (3 + a newline), but the data is the old file
> contents.
??? The bytecount should be 4 for both files in Franks case, I think.
Anyway, it is wrong on the Linux server as well in my case.
> If this behavior is reproducible, could you try doing a lookup of xyzzy
> on the server to turn on debugging, then repeat the file creation
> process?
It is completly reproducible. Unfortunately, I am not sure what this
xyzzy-thing is supposed to do. It did nothing for me. Grep'ing through
the kernel source shows that xyzzy is used in the nfs *client* code (and
the ufs code).
-- Thomas
PS: I read linux-kernel in digested form, so I am lagging somewhat behind
the list.