From: Doug McNaught <doug@wireboard.com>
To: psusi@cfl.rr.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [bug report] NFS and uninterruptable wait states
Date: 03 Sep 2001 11:50:17 -0400 [thread overview]
Message-ID: <m3zo8cp93a.fsf@belphigor.mcnaught.org> (raw)
In-Reply-To: <01090310483100.26387@faldara>
In-Reply-To: Phillip Susi's message of "Mon, 3 Sep 2001 10:48:31 +0000"
Phillip Susi <psusi@cfl.rr.com> writes:
> The other day I was trying to set up an NFS mount to my room mate's system,
> and ran into what I at least, call a bug. When I tried to mount his NFS
> export, the mount command locked up, and would not die. Not even a SIGKILL
> would do any good. According to ps, the mount process was in the 'D' -
> uninterruptable wait state. It also looked like the WCHAN was rpc_
> something. I think it was waiting for an rpc call to return in the D state,
> and it never did return. The bug here is that it should NOT be waiting in
> the D state for something that could never happen. For that matter, why
> should anything ever need to wait in an uninterruptable state? Whenever you
> wait, you should expect the possibility of being interrupted, check for that
> when you wake up, and if you were, clean up and return so the signal can be
> processed.
NFS does this (wait in D state) by default in order to prevent naive
applications from getting timeout errors that they're not equipped to
handle--the idea being that, if an NFS server goes down, programs
using it will simply freeze and recover once it returns, rather than
getting a timeout error and possibly becoming confused.
If you don't like this behavior, mount with 'soft' and/or 'intr'
options--see the manpage.
-Doug
--
Free Dmitry Sklyarov!
http://www.freesklyarov.org/
We will return to our regularly scheduled signature shortly.
next prev parent reply other threads:[~2001-09-03 15:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-03 10:48 [bug report] NFS and uninterruptable wait states Phillip Susi
2001-09-03 15:11 ` Peter Wächtler
2001-09-03 15:17 ` Peter Wächtler
2001-09-03 15:50 ` Doug McNaught [this message]
2001-09-03 11:55 ` Phillip Susi
2001-09-03 17:42 ` Doug McNaught
2001-09-03 16:28 ` David Woodhouse
2001-09-03 17:09 ` Peter Wächtler
2001-09-03 17:14 ` David Woodhouse
2001-09-03 17:50 ` Doug McNaught
2001-09-10 13:53 ` Jan Hudec
2001-09-03 22:11 ` Sound Blaster Live - OSS or Not? Thiago Vinhas de Moraes
2001-09-03 22:26 ` Tim Jansen
2001-09-03 22:26 ` Thiago Vinhas de Moraes
2001-09-03 22:51 ` Robert Love
2001-09-04 3:38 ` Garett Spencley
2001-09-03 23:03 ` Joel Jaeggli
2001-09-03 23:35 ` machack
2001-09-04 10:54 ` Daryl F
2001-09-04 12:09 ` rui.p.m.sousa
2001-09-04 17:08 ` Thiago Vinhas de Moraes
2001-09-04 17:36 ` rui.p.m.sousa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3zo8cp93a.fsf@belphigor.mcnaught.org \
--to=doug@wireboard.com \
--cc=linux-kernel@vger.kernel.org \
--cc=psusi@cfl.rr.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.