Page fault, GEOM problem??

[Pawel Jakub Dawidek]

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):
+> 
+> root at elfi:/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
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20051119/19aeb0a8/attachment.bin