Bug#367125: knfsd / bad inode number on ext3
We're also seeing this bug with 2.6.15 after replacing disks in an NFS
server. It seems worth mentioning that the new filesystem has fewer
inodes, both in use and available total than the old filesystem.
In the kernel source, look at nfs_vfs_read() in fs/nfsd/vfs.c. It's
called through about a half-dozen other functions from the top level
nfsd_proc_read(). It looks like it's getting the inode number from a
structure which originated in the NFS read request itself and I don't
see anything doing validation. The code in ext3 appears to assume that
the only source of unchecked inode numbers is the filesystem itself
(like a corrupted directory), so attempting to access one which does not
exist is an error that triggers the filesystem error behavior (continue,
remount-ro, or panic).
I see a similar report from late 2003 on RH's web site at
http://www.redhat.com/archives/ext3-users/2003-December/msg00024.html ,
which suggests it's a longstanding but infrequently occurring bug.
The exporter's method of generating the fsid also seems suspect. The
exports manual page says it's generated from the block device
major/minor but maybe it ought to come from the filesystem UUID instead
to avoid the case where clients have stale FH's pointing at non-existent
or wrong files if a filesystem needs to be remade. Such a method would
also avoid unnecessary E_STALE's when the physical attachment of disks
in a system changes. I'll open a separate bug for that problem.
"This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
Reply to: