We have a machine that is trying its darndest to house a linux kernel
cvs repository.
The machine is a dual 733mhz p3 netfinity of some kind. 512M of mem.
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/sda1 16484504 4015876 11631240 26% /
/dev/sda2 31079 3199 26276 11% /boot
/dev/sdb2 16516084 32828 15644264 1% /disk/sdb2
/dev/sdc1 141905076 344080 137235980 1% /disk/sdc1
$ grep sd /etc/fstab
/dev/sda1 / ext3 defaults,errors=remount-ro 0 1
/dev/sda3 none swap sw 0 0
/dev/sdb1 none swap sw 0 0
/dev/sda2 /boot ext3 defaults,rw 0 2
/dev/sdb2 /disk/sdb2 ext3 defaults,rw 0 2
/dev/sdc1 /disk/sdc1 ext3 defaults,rw 0 2
sda and sdb are boring direct attached
Vendor: IBM Model: DDYS-T18350M Rev: S93E
sdc is the ext3 partition on the ~140gig megaraid device in write-through
mode. I'm pretty sure its using ordered data mode.
the kernel on the machine is a home-compiled 2.2.19 + 0.0.7a with most
everything statically compiled in, SMP enabled, CONFIG_1G. I've attached
the .config that generated it.
The problem occurs when we try to run a perl script that runs remotely
and synchronizes a kernel.org mirror with a cvs repository on this
machine. the perl script does lots of importing and rtaging, which
generates all kinds of small-file load on the enormoid ext3 partition.
the script will run fine for about 10 or 15 minutes or so, then the
asserts happen. it can usually be reproduced after a few tries.
I've attached the raw oops and the output of ksymoops. We're way too
clever to actually use a serial console on the machine, so the oops
is transcribed from a digital photo of the console. If we screwed up
typing it in, we can send urls to the photos :)
is this something we can help fix? or should we just upgrade to
2.4.9+0.9.[56]?
--
zach
