I'm still running into NFS client problems on 2.4.0-test1-ac15
running against a 2.2.14 knfsd server. The system is stable with
2.2.14 NFS client running against 2.2.14 knfsd server.
In this particular setup, device 0x305 is only used by one client.
(It contains the NFS export for the root-NFS client).
It normally ends up with complaints about inode number mismatches
from the 2.4.0 client, and the occasional EIO error.
It seems almost although the knfsd server seems to be randomly
choosing inode numbers to give to the client.
Ok, this is getting really weird... I just rebooted the client again, and
got something very wrong happen. On the knfsd server:
bash# cd /var/boot/caramon/lib/modules/2.4.0-test1-ac15
bash# vdir net fs
fs:
total 43
-rw-r--r-- 1 root root 42976 Jun 12 14:43 minix.o
net:
total 58
-rw-r--r-- 1 root root 7176 Jun 12 14:43 bsd_comp.o
-rw-r--r-- 1 root root 49592 Jun 12 14:43 ppp_deflate.o
On the client:
bash# vdir /lib/modules/2.4.0-test1-ac15/fs
vdir: /lib/modules/2.4.0-test1-ac15/fs/bsd_comp.o: No such file or directory
total 0
Err, but bsd_comp.o never existed in fs! What's more is that the client
has only been up for 5 minutes, and the files were placed into the directories
from the 2.2.14 client at least 30 minutes previously.
>From that particular boot, nfs related/error messages are:
nfs_refresh_inode: inode number mismatch
expected (0x305/0x1dd0), got (0x305/0x347b)
^- var/run/utmp ^- var/run/wtmp
/etc/rc.d/rc.sysinit: /etc/HOSTNAME: I/O error
nfs_refresh_inode: inode number mismatch
expected (0x305/0x2cdc), got (0x305/0xeec)
^- root/.Xauthority ^- boot/vmlinuz-2.4.0
Here's another one from early on during boot:
INIT: version 2.64 booting
FPEmulator V4.07 (c) Acorn Computers Ltd. [ UMULL NoFPC ]
<disclaimer message>
nfs_refresh_inode: inode number mismatch
expected (0x305/0x1dd0), got (0x305/0x347b)
Creating 128k RAM disk [ OK ]
Making FS on /dev/ram [ OK ]
Now, there's not a lot which goes on around here. init starts running
/etc/rc.d/rc.sysinit. rc.sysinit is very close to the RedHat version,
but with a couple of modifications to get:
1. loopback network device running
2. remove /etc/mtab early
3. create a 128k ram disk for /var/lock
The inode numbers here refer to the following files:
0x1dd0 /var/run/utmp (on server before boot relative to clients root
mount point, and on client after boot)
0x347b /var/log/wtmp (on server before boot relative to clients root
mount point, and on client after boot)
Later on, I get:
Starting sendmail: nfs_refresh_inode: inode number mismatch
expected (0x305/0x87a), got (0x305/0x87c)
makemap: cannot open type hash map /etc/mail/virtusertable.db
nfs_refresh_inode: inode number mismatch
expected (0x305/0x87b), got (0x305/0x87d)
nfs_refresh_inode: inode number mismatch
expected (0x305/0x87b), got (0x305/0x87d)
[ OK ]
The inode numbers here are:
0x87a /etc/mail/virtusertable.db
0x87b /etc/mail/access.db
0x87c /etc/mail/domaintable.db
0x87d /etc/mail/mailertable.db
These inode numbers are confirmed on the server prior to the boot, and
on the client post-boot.
Any ideas what's going on? Unfortunately without a version of tcpdump which
decodes knfsd filehandles to device/inode, it's not easy to track the NFS
activity. Is there a patch for tcpdump?
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King rmk@arm.linux.org.uk --- ---
| | | | http://www.arm.linux.org.uk/~rmk/aboutme.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Jun 15 2000 - 21:00:26 EST