2.0: nfs_refresh_inode: inode number mismatch

Edvard Tuinder (ed@praseodymium.cistron.nl)
9 Jun 1996 23:46:40 +0200


Well, first thing today was installing 2.0.
Second thing today was reverting to 1.99.2 (last one tried).

Situation:
Running linux-2.0 on one host, which mounts my home directory from
a solaris-2.5 box over ethernet.

What happens:
nfs traffic between linux and solaris _appears_ to be broken on the
solaris side, but up until 1.99.2 I had no problem with nfs.

I just ran trn, when quitting, it creates a .newnewsrc, if succesfull,
removed .newsrc and renames .newnewsrc to .newsrc.

The .newsrc file is truncated though. During a quit on trn, linux
displays the nfs_refresh_inode errors. During this particular session,
the .newsrc file gets truncated to 4k (my read and write options on nfs
mounts), though the solaris server ack's both writes, once 4096 and one 2041.

The behaviour is not consistent, sometimes all is fine and then files
get truncated (like the previous message about this ;-() at random sizes,
zero or N * 4096.

Anyway, below is output from snoop run on the solaris box, the sample is
only from the write and move actions.:

linux -> solaris NFS C LOOKUP2 FH=20C4 .newnewsrc
solaris -> linux NFS R LOOKUP2 No such file or directory
linux -> solaris NFS C CREATE2 FH=20C4 .newnewsrc
solaris -> linux NFS R CREATE2 OK FH=5CCD
linux -> solaris NFS C LOOKUP2 FH=20C4 .newsrc
solaris -> linux NFS R LOOKUP2 OK FH=18B4
linux -> solaris NFS C SETATTR2 FH=5CCD
solaris -> linux NFS R SETATTR2 OK
linux -> solaris NFS C SETATTR2 FH=5CCD
solaris -> linux NFS R SETATTR2 OK
linux -> solaris UDP continuation ID=2742
linux -> solaris UDP continuation ID=2742
linux -> solaris NFS C WRITE2 FH=5CCD at 0 for 4096
solaris -> linux NFS R WRITE2 OK
linux -> solaris UDP continuation ID=2743
linux -> solaris NFS C WRITE2 FH=5CCD at 4096 for 2041
solaris -> linux NFS R WRITE2 OK
linux -> solaris NFS C REMOVE2 FH=20C4 .newsrc
solaris -> linux NFS R REMOVE2 OK
-> linux -> solaris NFS C RENAME2 FH=20C4 .newnewsrc to FH=20C4 .newsrc
solaris -> linux NFS R RENAME2 OK
linux -> solaris NFS C LOOKUP2 FH=20C4 .rnlock
solaris -> linux NFS R LOOKUP2 OK FH=8EC7
linux -> solaris NFS C REMOVE2 FH=20C4 .rnlock
solaris -> linux NFS R REMOVE2 OK

Though I'm not an NFS wizard, the tagged line looks (logically) wrong to
me, but I can be wrong.

Any insight would be appreciated, since this way I can't mount any nfs
partitions on my linux box without risking data loss.

Ed

-- 
Edvard Tuinder
Cistron Internet Services		Finger ed@cistron.nl for PGP key
   ``old unix hackers don't die, they just turn into zombie processes.''