All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Peter Wächtler" <pwaechtler@loewe-komp.de>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [bug report] NFS and uninterruptable wait states
Date: Mon, 03 Sep 2001 19:09:50 +0200	[thread overview]
Message-ID: <3B93B95E.F30F1F8B@loewe-komp.de> (raw)
In-Reply-To: <m3zo8cp93a.fsf@belphigor.mcnaught.org>  <01090310483100.26387@faldara> <32526.999534512@redhat.com>

David Woodhouse wrote:
> 
> doug@wireboard.com said:
> >  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.
> 
> Timeouts are a completely separate issue, surely? Applications ought to be
> able to deal with getting a _signal_ during a system call, whatever happens.
> 
> IMO, sleeping in state TASK_UNINTERRUPTIBLE in any situation where you can't
> prove that the wakeup _will_ happen and will happen _soon_ should be
> considered a bug - it's almost always just because someone hasn't bothered
> to implement the cleanup code required for dealing with being interrupted.
> 
> /me tries to work out why anyone would ever want filesystem accesses to be
> uninterruptible.
> 
Because historically the 'D' meant "wait on _D_isk" 8-)

  reply	other threads:[~2001-09-03 17:09 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
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 [this message]
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=3B93B95E.F30F1F8B@loewe-komp.de \
    --to=pwaechtler@loewe-komp.de \
    --cc=dwmw2@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    /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.