[lkml]   [2001]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [bug report] NFS and uninterruptable wait states
Phillip Susi <> 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.

Free Dmitry Sklyarov!

We will return to our regularly scheduled signature shortly.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:02    [W:0.249 / U:1.820 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site