Please stop apps going into state D uninterrupted sleep !!

[Patrick O'Callaghan]

On Tue, 2012-05-08 at 19:42 -0400, Sam Varshavchik wrote:
> Patrick O'Callaghan writes:
> 
> > On Tue, 2012-05-08 at 15:35 -0700, Joe Zeff wrote:
> > > On 05/08/2012 03:17 PM, Sam Varshavchik wrote:
> > > >
> > > > It's not up to the app. This is not an optional system call. If the
> > > > kernel wants to put the task into uninterruptible sleep, that's what it
> > > > will do. End of story.
> > >
> > > So let me get this straight: even if you know that this kind of thing
> > > can happen and want to leave an escape switch available you can't simply
> > > tell the kernel not to use this feature.  Interesting.
> >
> > It's not a "feature", as in some optional extra, it's a fairly
> > fundamental aspect of how the kernel works. Any book on kernel hacking
> > will tell you the same. This is not to say that it couldn't be any other
> > way, but actually changing it would mean quite a radical redesign.
> > Nothing is impossible, but I wouldn't hold my breath if I were you.
> 
> No, this still misses the point.
> 
> If you do not want the kernel to put a process into uninterruptible sleep,  
> waiting for a broken mount to come back up, all you have to do is NOT  
> specify a non-default mount option.
> 
> Processes go into uninterruptible sleep if the remote share gets mounted  
> with the "hard" option.
> 
> Use soft mounts. Problem solved.

*For NFS*, but there's no indication that the OP's problem is being
caused by NFS. Other things can also cause D state waits (in fact every
disk access causes them, it's just that they terminate very quickly
unless there's an actual fault). My reply was aimed at the general case.

poc