Message from discussion
Something stronger then kill -9
Message-ID: <3DE3C6E2.CEBA9653@sympatico.ca>
From: John-Paul Stewart <jpstew...@sympatico.ca>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
Newsgroups: comp.os.linux.misc
Subject: Re: Something stronger then kill -9
References: <c673867.0211210922.1aabea69@posting.google.com> <slrnatq9ru.phc.avenj@cerberus.localhost> <arjbhk$5eu$1@bob.news.rcn.net> <j5rlra.ucb.ln@freenet.co.uk> <arufj5$j3u$1@omega-3.right.here> <dukvra.m31.ln@freenet.co.uk>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 38
Date: Tue, 26 Nov 2002 14:09:22 -0500
NNTP-Posting-Host: 65.93.155.5
X-Complaints-To: abuse@sympatico.ca
X-Trace: news20.bellglobal.com 1038339001 65.93.155.5 (Tue, 26 Nov 2002 14:30:01 EST)
NNTP-Posting-Date: Tue, 26 Nov 2002 14:30:01 EST
Organization: Bell Sympatico
Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!logbridge.uoregon.edu!snoopy.risq.qc.ca!torn!webster!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!penguin.no.domain!news
spi...@freenet.co.uk wrote:
>
> rnich...@interaccess.com wrote:
> > In article <j5rlra.ucb...@freenet.co.uk>, <spi...@freenet.co.uk> wrote:
> > :Morden <newsp...@nowhere.com> wrote:
> > :> I think it's normal for a process to be non-killable when waiting for
> > :> some I/O. If I/O the process's waiting for never happens the process can
> > :> not be killed. Try to find out what the process is waiting for.
> > :> Maybe there's something in /proc that can be used to find that out?
> > :
> > :Shame the process can't timeout when in such a state... locked D processes
> > :should be *eventually* recoverable. No hardware wait should require more
> > :than half an hour.
>
> > Here's one contrary data point. An "ERASE" command to a DDS-2 tape
> > drive takes roughly 3 hours to complete. That's with the "long" bit
> > set, which is what is compiled into the kernel's "st" driver.
>
> That's the entire action though isn't it? The process isn't in a "D" state
> all that time. It has to be actively erasing the tape for most of it.
I don't think the process is actually "actively erasing the
tape". It is my understanding that the application simply
sends an "erase" command of some sort to the tape and waits
for it to complete, with the hardware doing the work.
I'm not the one who made the comment about erasing a DDS-2
tape, but I can say this: on a Travan tape, a seek done
with 'mt fsf 1' remains in state "D" until the seek
completes. (The application is doing nothing while the
hardware does the seek.) With ~8GB in a single tar archive,
that could take _hours_ to get there on my Travan drive.
Some hardware does indeed require more than a half hour wait
in "D" state.
J-P Stewart
|
