From owner-freebsd-stable@FreeBSD.ORG Sat Nov 19 00:55:17 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 372A916A41F; Sat, 19 Nov 2005 00:55:17 +0000 (GMT) (envelope-from johan@stromnet.org) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9531B43D45; Sat, 19 Nov 2005 00:55:16 +0000 (GMT) (envelope-from johan@stromnet.org) Received: from elfi2.stromnet.org (81.231.107.13) by pne-smtpout1-sn2.hy.skanova.net (7.2.060.1) id 437DDE810001BE8B; Sat, 19 Nov 2005 01:54:59 +0100 Received: from localhost (localhost [127.0.0.1]) by elfi2.stromnet.org (Postfix) with ESMTP id 31C00CF03F; Sat, 19 Nov 2005 01:54:57 +0100 (CET) Received: from elfi2.stromnet.org ([127.0.0.1]) by localhost (elfi.stromnet.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19267-01; Sat, 19 Nov 2005 01:54:56 +0100 (CET) Received: from [10.10.0.6] (vpn1-c1.stromnet.org [10.10.0.6]) by elfi2.stromnet.org (Postfix) with ESMTP id 03929CF023; Sat, 19 Nov 2005 01:54:55 +0100 (CET) In-Reply-To: <1132353600.903.19.camel@genius1.i.cz> References: <991F35AA-151B-4AEA-82BD-5F4AEDF28424@stromnet.org> <74994962-5050-47BD-897B-DE3880B9EBD5@stromnet.org> <1132353600.903.19.camel@genius1.i.cz> Mime-Version: 1.0 (Apple Message framework v746.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Johan_Str=F6m?= Date: Sat, 19 Nov 2005 01:55:57 +0100 To: Michal Mertl X-Mailer: Apple Mail (2.746.2) X-Virus-Scanned: amavisd-new at stromnet.org Cc: delphij@delphij.net, pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Page fault, GEOM problem?? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Nov 2005 00:55:17 -0000 On 18 nov 2005, at 23.39, Michal Mertl wrote: > Johan Str=F6m 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 =20 > larger > filesystems so the swap has to be enabled. Core dumps are written =20 > 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 =20 > corrupts the > core dump you may start after next crash in single user mode and =20 > 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 =20 > that > even wedged kernel can be dumped. The dumping code is part of hard =20 > disk > controller's drivers. The gmirror is quite high-level device and geom > itself needs working scheduler so there will probably never be a =20 > 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@elfi:/home/johan$ time dd if=3D/dev/zero of=3Dbigfile.zero bs=3D1024 = =20 count=3D1000000 1000000+0 records in 1000000+0 records out 1024000000 bytes transferred in 77.014797 secs (13296146 bytes/sec) real 1m17.100s user 0m0.244s sys 0m10.140s 13MB/s from /dev/zero?? This was to my home dir (gm0s1f, last label =20 on the slice/disk)).. When I'm about to open a new window in screen (ctrl-a-c) it takes =20 forever (or rather, bash takes forever) to init when the above dd is =20 running... Well, iostat during dd: johan@elfi:~$ iostat tty ad0 ad6 =20 ad10 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy =20 in id 0 164 2.19 0 0.00 50.52 3 0.17 50.99 3 0.17 1 0 =20 1 1 97 0.17MB/s?? Am i missreading these iostats or something?.. Load averages directly after the dd is complete is at 0.36, 0.15, =20 0.05, so the dd doesnt take that much of aload to make bash work soo =20 slow...Gotta be something else... Running diskinfo -t gives me good values (for /dev/ad6 and /dev/ad10) Transfer rates: outside: 102400 kbytes in 1.846578 sec =3D 55454 =20 kbytes/sec middle: 102400 kbytes in 1.879855 sec =3D 54472 =20 kbytes/sec inside: 102400 kbytes in 3.147158 sec =3D 32537 =20 kbytes/sec So it shouldnt be the disk itself.. those values are the same as when =20= I hade the disk in the "temp" system.. However I never did try any dd =20= speedtests there. Btw, tried to do regular cp on a dirtree at some gigs, same slooow =20 speed.. Maybee my customkernel is fuckedup or something? It's just a GENERIC =20 with some nonused devicedrivers removed so it would be strange... I'll recompile during night and test GENERIC tomorrow, reporting back.. Did try to move the cards (network/vga/sata) arround in the PCI =20 ports, in case there were any strange conflicts... No difference =20 except I only got one txerror from xl since last boot (wooh!) No crash so far. -- Johan