[lkml]   [2001]   [Sep]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] lazy umount (1/4)
On Mon, 17 Sep 2001, Alex Stewart wrote:

> 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

> 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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:03    [W:0.051 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site