> 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
Well, you cannot tell your local power plant "you must not fail this
very moment" either. Of course, data will be lost when a process is
killed from "D" state, but if the admin can tell the data will be lost
either way, ...
Anyways, I'm going to try the forced umount patch real soon now.
> 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).
Well, with journals, phase trees/soft updates (hint!) that's less of an
issue.
> 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.
You were faster than me with this post ;) With unpatched 2.2, I once
had a machine stuck with an exhausted process table.
-- Matthias Andree"Those who give up essential liberties for temporary safety deserve neither liberty nor safety." - Benjamin Franklin - 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/