Alan Cox [quoting from Matthias Andree] wrote:
>>Well, from a practical point of view two things that would really help
>>Linux:
>>
>>1) Be able kill -9 processes from "D" state.
Please note that there is a reason why the "D" state exists, and it is
because there are certain times when interrupting a process can have
significant consequences on the integrity of the entire filesystem (or
other global resource) and must not be allowed for consistency. As it
happens, most of the conditions which cause processes to get "stuck" in
disk-wait state (usually because of hardware issues) happen to be
exactly the places where it's most difficult to work around this (at
least for physically-backed filesystems, less so for NFS et al).
This, I assume, is at least part of the reason why Alan Says:
> Wont happen.
(and I would tend to agree)
>>2) Force unmount busy file systems and kill -9 all related processes.
>>
>
> umount -f
...doesn't do anything for non-NFS filesystems, though. There isn't
even a hook for it in any of the other FS drivers.
>>down, there is ABSOLUTELY NO WAY of getting rid of the mounts besides
>>losing unrelated data (i. e. unmount in background, killall -9 rpciod -
>>will possibly lose data written to other servers).
>>
>
> umount -f.
(for NFS) does work most of the time. I'm not quite sure why, but in
some cases I've needed to combine this with mounting things 'intr' so I
could manually kill processes off.
>>ago, just because it does umount -f and Linux' ever-rising load with
>>stuck processes really annoys me and has brought one of my production
>>machines down more than once. Soft NFS mounts are not really an option.
>>
>
> The 'D' state stuff is not "load" - it didn't bring your box down, something
> else did.
Well, yes and no. It's not _CPU_ load, but the stuck processes can
consume other limited resources (memory, file descriptors, etc) to the
point that the system is unable to function properly if enough of them
accumulate. I have also had this happen.
-alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Sep 23 2001 - 21:00:22 EST