Bug 84920 - nfs serving hangs local access to particular directory
nfs serving hangs local access to particular directory
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
9
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Steve Dickson
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-02-23 16:58 EST by Alexandre Oliva
Modified: 2007-04-18 12:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-05-11 16:03:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexandre Oliva 2003-02-23 16:58:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030206

Description of problem:
This may look similar to bug 82984, but I don't think it's the same problem. 
Here's what happened:

The NFS server is my desktop, running under very light load.

I was doing an NFS install to my wife's desktop, mouting the ISOs from my desktop.

Another machine had another filesystem mounted from my desktop, and was doing
some relatively light access to files in my desktop, converting avi files from
one format to another.

Just as I heard the beep from my wife's machine, saying the install had
completed and it was now rebooting, I noticed that the avi compressor had hung.
 The window of the application wouldn't refresh any longer, and I couldn't put
it in background any more.

On the local machine (the NFS server), I tried to access the directory the media
converter was accessing.  ls hang.  Other directories in the same filesystem
appeared to be ok.  Hmm, now I realize I may not have actually tried anything on
this filesystem, as the shell blocked and other shells I had were on another
filesystem.  

Oops, this may turn out to be the same problem as 82984, even though it's a
different kernel version (running 2.4.20-2.48 now) and I haven't run into the
bug with a local nfs mount despite some heavy loads I put on it.

I've had at least one other hang similar to this the other day, but I couldn't
correlate it with an NFS unmount at that time.  Not that I'm sure it's related,
but it may be, since I had just started the conversion of one file, so it was
working just a few seconds before the other NFS client rebooted.

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


How reproducible:
Sometimes

Steps to Reproduce:
1.Start one NFS client creating directories and, say, copying not-very-large
files in one filesystem mounted from the server
2.Start an NFS install on another machine mounting from the same NFS server, but
from another filesystem
3.Wait for the install to complete, and let it reboot.


Actual Results:  If you're lucky (or not :-) the other NFS client will hang, and
so will the NFS server, as far as access to the affected directory (or maybe the
filesystem containing it) is concerned.  Unfortunately, it didn't generate a
kernel oops, AFAICT.

Expected Results:  This Shouldn't Happen (TM) :-)

Additional info:
Comment 1 G.S. Link 2003-03-20 15:02:17 EST
Could this be part of the following:  If you connect to a remote NFS server and
mount an NFS drive and then the remote NFS server goes away you will not be able
to do a clean power down or unmount the drive?  This condition showed up in the
lab but I wasn't sure it was a bug so didn't report it.  This condition has
existed since at least ver 5.
Comment 2 Alexandre Oliva 2003-03-20 15:50:34 EST
I don't see how these conditions could be related.  One thing is the server
hanging when accessing a filesystem that was NFS-exported, the other is the
client hanging because the server is not there.  The latter is bug 63602.
Comment 3 Alexandre Oliva 2003-05-11 16:03:13 EDT
Never got this with Shrike.  Presumably fixed with the removal of the buggy ACL
patch.

Note You need to log in before you can comment on or make changes to this bug.