Messages in this thread |  | | Subject | Re: 2.0: nfs_refresh_inode: inode number mismatch | Date | Wed, 12 Jun 1996 20:24:08 +0200 | From | Olaf Kirch <> |
| |
Hi Ed,
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.
|  |