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 -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
