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