Etch - Latchups - Disks very slow with software RAID

Hi, I just installed Etch on my primary server, and I can't believe how slow the disks are. It takes about 2 hours to copy 1.5 GB on the same partition.

Not only does it take forever, but the entire machine hangs for minutes at a time while the transfer is occurring. No actual crashes though.

I am using a Supermicro P3TDER/P3TDEI motherboard. This machine has been working great with FreeBSD.

I have checked with hdparm and am using all the appropriate settings. Various hdparm permutations had the predicable effects when measuring with hdparm -Tt. But no effect on the overall slowness with large files.

I used iostat to look at transfer rates while copying large files. I found that the machine would transfer no data for 10 seconds or so, and then transfer a burst for a few seconds.

I am also using linux software RAID-1 so that may also be clouding the issue.

Does anyone have any suggestions about how to go about debugging this?

Thanks.

chucnk size and block size for large files may be off a tad.
Thats all I can say,until you narrow it down,what process is useing the cpu power during transfer?

I've looked at your post several times trying to figure out a way to help you. Have you tried running "top" during a copy to see where the CPU is spending its time? I can't imagine that the fact that it's a software RAID1 has anything to do with it, otherwise people would be screaming all over the place. Does this motherboard have multiple processors? What disk controller does it use? (run lspci) How much memory do you have, and is the thing swapping like crazy?

Hi, thanks for making the effort to help.

To answer your questions, it is a dual P3,
1266 MHz machine. It has 512MB. Swap
is not being used. When not testing, it
sits idle with 213MB in use. When testing
almost all physical memory is used, but swap
is not.

The problem did not show up when I installed
the machine, and I haven't had a chance to go
back to the colo facility and look at the drive
light activity when testing.

I also tried using different schedulers, with no
noticable effect.

I think that I might be having the same issue
that these people are having:

http://forums.gentoo.org/viewtopic-t-482731.html

http://bugzilla.kernel.org/show_bug.cgi?id=7372

On a tip, I tried reverting to kernel 2.6.17.14 with no luck.
When I have some time I want to try the latest kernel.org
kernel.

I've been running bonnie++ in order to duplicate the
problem. A big copy also triggers the issue.

When running bonnie++, top does not update much, but
when it does I either see:

us: 0%
sy: 0%
ni: 0%
id: 50%
wa: 50%
hi: 0%
si: 0%
st: 0%

or

us: 0%
sy: 0%
ni: 0%
id: 99%
wa: 0%
hi: 0%
si: 0%
st: 0%

In both cases I don't see any processes taking up
CPU time.

lspci gives this output:

00:00.0 Host bridge: Broadcom CNB20HE Host Bridge (rev 23)
00:00.1 PCI bridge: Broadcom CNB20LE Host Bridge (rev 01)
00:00.2 Host bridge: Broadcom CNB20HE Host Bridge
00:00.3 Host bridge: Broadcom CNB20HE Host Bridge
00:04.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)
00:06.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] (rev 08)
00:0f.0 ISA bridge: Broadcom CSB5 South Bridge (rev 93)
00:0f.1 IDE interface: Broadcom CSB5 IDE Controller (rev 93)
00:0f.2 USB Controller: Broadcom OSB4/CSB5 OHCI USB Controller (rev 05)
00:0f.3 Host bridge: Broadcom CSB5 LPC bridge
01:00.0 VGA compatible controller: ATI Technologies Inc Rage XL AGP 2X (rev 27

I'd really appreciate any help or ideas.

Do you see any errors when you run dmesg? I just did a test against my software RAID0 with promise controller. It took 4 minutes 51 seconds to copy a 4.7GB file. My chunksize is the 64K default. I just don't have any real ideas for you.