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 [EMAIL PROTECTED] -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
