I've been staring at the code for a while now and can't figure out what
may cause your problem.
I have a vague idea how the truncation may happen without the application
issues an error message, though. In nfs_file_write (nfs/file.c), if
the RPC call returns an error, it breaks out of the loop, and returns
the number of bytes written so far rather than an error. If trn only
checks that the result of write() is non-negative, the error may go
unnoticed. That does not explain why the RPC call failed, and where the
nfs_refresh_inode message comes from, though. (When nfs_file_write
bails out of the loop, fattr should contain valid attributes from the
previous nfs_proc_write call.)
Can you please try what happens if you compile NFS with debugging enabled
and send me the output of a failed write?
[To enable debugging, activate the #define NFS_PROC_DEBUG in fs/nfs/proc.c,
and do an `ls xyzzy' on the NFS-mounted filesystem to toggle trace mode.
For hard-core debugging, enable DEBUG_RPC in fs/nfs/rpcsock.c--the amount
of printk activity is usually so much that many race condition problems
are not reproducible with debugging enabled... sort of a Heisenberg-FS :-)]
: -> linux -> solaris NFS C RENAME2 FH=20C4 .newnewsrc to FH=20C4 .newsrc
: solaris -> linux NFS R RENAME2 OK
: Though I'm not an NFS wizard, the tagged line looks (logically) wrong to
: me, but I can be wrong.
The line appears alright to me (the file handle given is that of the
directory, not the file to be renamed).
Cheers
Olaf
-- Olaf Kirch | "Zerschlagt die Computer...." | --- o --- Nous sommes okir@monad.swb.de | Georg Danzer | / | \ du soleil.