On Sat, Nov 19, 2005 at 01:55:57AM +0100, Johan Ström wrote: +> +> On 18 nov 2005, at 23.39, Michal Mertl wrote: +> +> >Johan Ström wrote: +> >>Hi! +> >> +> >>On 18 nov 2005, at 18.43, Xin LI wrote: +> >> +> >>>Hi, Johan, +> > +> >< large snip> +> > +> >>So, it seems it does run savecore after running dumpon and mounting +> >>disks etc... Is that wrong? +> > +> >No, this is normal. When you run savecore you need to have mounted +> >filesystems. In order to mount the filesystems they may have to be +> >checked. The fsck program requires big amount of memory to check larger +> >filesystems so the swap has to be enabled. Core dumps are written to the +> >dump device (swap) from the end whereas the swap is normally used from +> >the beginning (or the other way around). Therefore there's quite a big +> >chance that, even when the swap has to be used for fsck, the core dump +> >is intact and usable. If the usage of the swap file by fsck corrupts the +> >core dump you may start after next crash in single user mode and run the +> >commands manually (without enabling swap). +> > +> >As to why you can write kernel core dumps only to certain devices the +> >answer is that at the time, when the kernel is dumping core, it is +> >usually in pretty bad state, kernel internals may be corrupted and so +> >on. The dumping code is therefore written to be quite low level so that +> >even wedged kernel can be dumped. The dumping code is part of hard disk +> >controller's drivers. The gmirror is quite high-level device and geom +> >itself needs working scheduler so there will probably never be a way to +> >dump on gmirror provided swap. When you issue the dumpon command the +> >check is performed whether the driver for the disk you want to dump on +> >supports kernel core dumps. +> > +> >Michal +> +> Well that makes sense... Then that is right at least.. :) +> +> I just noticed another thing... My disk performance... sucks! :P +> +> Some examples (from an otherwise unloaded system): +> +> [EMAIL PROTECTED]:/home/johan$ time dd if=/dev/zero of=bigfile.zero bs=1024 count=1000000 +> 1000000+0 records in +> 1000000+0 records out +> 1024000000 bytes transferred in 77.014797 secs (13296146 bytes/sec)
You won't get more with such small block size. Try bs=128k. -- Pawel Jakub Dawidek http://www.wheel.pl [EMAIL PROTECTED] http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am!
pgp7quhqt8Cdm.pgp
Description: PGP signature
