Date: Sat, 19 Nov 2005 01:55:57 +0100 From: =?ISO-8859-1?Q?Johan_Str=F6m?= <johan@stromnet.org> To: Michal Mertl <mime@traveller.cz> Cc: delphij@delphij.net, pjd@freebsd.org, freebsd-stable@freebsd.org Subject: Re: Page fault, GEOM problem?? Message-ID: <BEE8C957-9DB5-4A08-AAAE-A1E524F4E092@stromnet.org> In-Reply-To: <1132353600.903.19.camel@genius1.i.cz> References: <991F35AA-151B-4AEA-82BD-5F4AEDF28424@stromnet.org> <a78074950511180117r6d64db25o4ae37c0c5998e002@mail.gmail.com> <74994962-5050-47BD-897B-DE3880B9EBD5@stromnet.org> <a78074950511180943r57fd9d03r64efcc705001bc35@mail.gmail.com> <A6F22EE2-B1E6-44B5-B4C2-E77E1A24FEBB@stromnet.org> <1132353600.903.19.camel@genius1.i.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BEE8C957-9DB5-4A08-AAAE-A1E524F4E092>