public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Alex Stewart <alex@foogod.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Matthias Andree <matthias.andree@stud.uni-dortmund.de>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] lazy umount (1/4)
Date: Mon, 17 Sep 2001 17:24:01 -0700	[thread overview]
Message-ID: <3BA69421.6020304@foogod.com> (raw)
In-Reply-To: <E15ixGu-0006ym-00@the-village.bc.nu>

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


  reply	other threads:[~2001-09-18  0:10 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-14 19:01 [PATCH] lazy umount (1/4) Alexander Viro
2001-09-14 19:02 ` [PATCH] lazy umount (2/4) Alexander Viro
2001-09-14 19:03   ` [PATCH] lazy umount (3/4) Alexander Viro
2001-09-14 19:03     ` [PATCH] lazy umount (4/4) Alexander Viro
2001-09-14 20:43 ` [PATCH] lazy umount (1/4) Linus Torvalds
2001-09-14 20:54   ` Alexander Viro
2001-09-15 12:32 ` jlnance
2001-09-15 20:51   ` Mike Fedyk
2001-09-17 10:06     ` Matthias Andree
2001-09-16 16:37 ` Alex Stewart
2001-09-17  6:57   ` Forced umount (was lazy umount) Ville Herva
2001-09-17  7:03     ` Aaron Lehmann
2001-09-17  8:38       ` Alexander Viro
2001-09-17 10:21         ` Matthias Andree
2001-09-17 10:47           ` Tigran Aivazian
2001-09-17 23:21             ` Alex Stewart
2001-09-17 23:23               ` Xavier Bestel
2001-09-18  1:04                 ` Alex Stewart
2001-09-18 20:19                   ` Pavel Machek
2001-09-17  8:29     ` Xavier Bestel
2001-09-17  8:39       ` Alexander Viro
2001-09-17 10:04 ` [PATCH] lazy umount (1/4) Matthias Andree
2001-09-17 12:13   ` Alan Cox
2001-09-18  0:24     ` Alex Stewart [this message]
2001-09-18  0:39       ` Matthias Andree
2001-09-18  8:56         ` Alexander Viro
2001-09-18  9:08           ` Matthias Andree
2001-09-18 13:03             ` Alan Cox
2001-09-18  9:07     ` David Woodhouse
2001-09-17 14:43 ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3BA69421.6020304@foogod.com \
    --to=alex@foogod.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthias.andree@stud.uni-dortmund.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox