Bug 71658

Summary: (NFS IRIX)NFS mounts give Input/output error after NFS server reboot
Product: [Retired] Red Hat Linux Reporter: Alistair Riddoch <alriddoch>
Component: kernelAssignee: Steve Dickson <steved>
Status: CLOSED CURRENTRELEASE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.2CC: jmroth, tim.chambers
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-08-11 11:05:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Alistair Riddoch 2002-08-16 11:12:00 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020724

Description of problem:
Directories are mounted on a RedHat Linux client system from an SGI Irix NFS
server. The mounts are automatically handled by amd. If the server is rebooted,
the mount points sometimes go into some kind of error state where attempting to
read from anything mounted there gives an Input/output error, attempting to
umount gives a busy error, and attempting to use fuser to determine what
processes  are using the mounted directory gives an Input/output error. It seems
that the only way to clear the error is to reboot the client machine.

Version-Release number of selected component (if applicable):


How reproducible:
Sometimes

Steps to Reproduce:
I believe that in order to reproduce, one or more files on the mounted
NFS filesystem must be open when the NFS server is rebooted. It is not possible
to reproduce this problem reliably for any one mount point, but if our NFS
server is rebooted, it is almost inevitable that at least one of our 4 heavily
used client machines will need to be rebooted.

Actual Results:  Attempting to access any file in the NFS mounted directory
gives Input/output error.

Expected Results:  Access to the NFS mounted directory should work normally once
the NFS server is back up and running.

Additional info:

The machines in question have been updated to all the latest errata,
and while the problem most frequently occurs on the one running 7.2,
it also occurs on machines running 7.3. It is probable that the machine
most commonly affected is not because of the different version, but because it
makes heavier use of NFS mounted filesystems.

Comment 1 J.M.Roth 2003-03-28 00:57:39 UTC
I'm having a similar issue here.
My problem is the client is in fact the server which mounts some directories 
in order to share config files from a mutual nfs mount.
What I would find useful would be that nfs looked up the hostname each times 
it accesses the nfs server, since in this case srv1.domain.dyn might switch IP 
addresses sometimes.
Mar 28 01:30:42 cents kernel: nfs: server srv1.domain.dyn not responding, 
timed out
Mar 28 01:40:21 cents last message repeated 2 times
Mar 28 01:40:21 cents kernel: nfs_statfs: statfs error = 5
Mar 28 01:40:42 cents kernel: nfs: server srv1.domain.dyn not responding, 
timed out
Mar 28 01:41:41 cents kernel: nfs: server srv1.domain.dyn not responding, 
timed out
I've got the same remarks about umount (-f) and fuser as the reporter of this 
bug.

Comment 2 Tim Chambers 2003-08-27 23:57:00 UTC
I'm seeing this on Everest (ia64) running RHEL3 beta2.

# cd /store/ISO/redhat/taroon/ia64/
# ll
ls: taroon-SRPMS-beta2-ia64-disc3.iso: Input/output error
ls: MD5SUMS: Input/output error
ls: taroon-rhel3as-beta2-ia64-disc2.iso: Input/output error
ls: taroon-rhel3as-beta2-ia64-disc3.iso: Input/output error
ls: taroon-rhel3as-beta2-ia64-disc4.iso: Input/output error
ls: taroon-SRPMS-beta2-ia64-disc1.iso: Input/output error
ls: taroon-rhel3as-beta2-ia64-disc1.iso: Input/output error
ls: taroon-SRPMS-beta2-ia64-disc2.iso: Input/output error

The NFS server describes itself this way:
$ ssh test.lsy uname -a
Linux linuxtest.fc.hp.com 2.4.19-686-smp #1 SMP Tue Nov 19 00:58:50 EST 2002
i686 Pentium III (Cascades) GenuineIntel GNU/Linux
$


Comment 3 Steve Dickson 2004-08-11 11:05:47 UTC
This seems to work on later kernels.