tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: dumps & shutdown order (was Re: CVS commit: src/sys/arch)

At Tue, 30 Jun 2009 02:49:35 +0000, David Holland 
<> wrote:
Subject: Re: dumps & shutdown order (was Re: CVS commit: src/sys/arch)
> On Tue, Jun 30, 2009 at 11:03:42AM +1000, matthew green wrote:
>  >    I don't think you should do this.  It makes it unlikely we will ever get
>  >    a useful dump of a system which paniced from a filesystem problem.
>  > 
>  > it also means that filesystems won't get a final sync if the
>  > dump hangs, which i see occasionally.
> I was seeing this more than occasionally for a while. :-/
>  > i would prefer the old ordering, or at least a choice.

Indeed, most often for me on production systems it's most important that
the filesystems be left in the best possible state, and then if I can
get a crash dump as well that's good, but if not, well too bad, but at
least it'll hopefully be quicker and easier to get the system running

If you know you're getting unusable crash dumps from an ongoing problem
then you can flip to the more dangerous option and hopefully get a clean

> What I'd like is an easy way to abort a dump that's in progress, like
> by hitting spacebar or something. Then there's no need to push the
> reset button, and the ordering becomes less important.

Indeed, that would also be very helpful, especially when the reset
button is on the other side of the house/office/city/country/world.

However unless doing so also means continuing on with filesystem syncs
(and any other cleanups still feasible) then that's kind of a separate
discussion, no?

I'm curious though whether the new sparse dumps will occur so quickly in
common cases that one no longer has the stronger urge to interrupt them.

                                                Greg A. Woods
                                                Planix, Inc.

<>       +1 416 218-0099

Attachment: pgpAZTQvZldin.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index