On Wed, Nov 14, 2007 at 12:36:17PM +0100, Martin Husemann wrote:
> On Wed, Nov 14, 2007 at 12:26:23PM +0100, Petar Bogdanovic wrote:
> > My second question is about the dump-device topic mentioned in the
> > NetBSD-Guide:
> > 
> > 	``The normal swap area in our case is on raid0b but this can not
> > 	  be used for crash dumps as process scheduling is stopped when
> > 	  dumps happen. Therefore we must use a real disk device. However,
> > 	  nothing stops us from defining a dump area which overlaps with
> > 	  raid0b.''
> 
> Not that this is no longer true for -current, you can dump to raid0b
> now.
> 
> > If no `overlapping real disk device' is defined on wd[01], I assume
> > savecore(8) would eventually fail to do a core-dump but how fatal is
> > this on a remote server with no debugging possibilities?
> 
> There are two parts of an answer:
>  - Crashdumps are very valuable even if you can not debug on the remote
>    server that created them. You don't need remote console to use them.
>  - If you don't want (or can't create) crashdumps, it will not impact
>    your server in any way (as long as it does not crash).
> 
> I think worst case scenario is that you get a crash dump written to some
> swap partition but savecore will not save it. You can prevent the creation
> of the crashdump via "swapctl -D none".

I think I confused panic(9) and savecore(8), so my next question would
be: Where will panic(9) write on a non-current system when process
scheduling is stopped, resp. when raid0b doesn't exist any more and no
other dump-device is available?