Here's a short update on the latest with my SATA woes.
First, a correction: The distribution I originally had working was Red Hat Linux 9. After trying many distributions, some with interesting failure modes (e.g. Debian Sarge), I finally got around to Fedora Core 1 (I had to download it this afternoon!). This installs kernel 2.4.22, and it not only recognized my two SATA disks, but the existing LVM setup, too! Under the old installation (I don't recall the kernel version at the moment), I was getting disk-cache reads of ~87 MB/s and disk reads of 1.39 MB/s (as reported by hdparm -tT /dev/hde). Yes, appallingly slow, but it worked. With FC1, I get disk-cache reads of 1500 MB/s (!) and disk reads of ~57 MB/s.
After that, I had the job of getting the software RAID 1 working again, as one of the drives got out of sync. I eventually figured out I needed to use raidhotremove/raidhotadd (with no man page installed!). raidhotremove /dev/md0 /dev/hdg said the drive had already been removed, and raidhotadd /dev/md0 /dev/hdg got everything going again. W00t! Now it's happily resyncing at around 10 MB/s (est. 250 mins to completion) according to cat /proc/mdstat.
Maybe I should mention that the on-board SATA controller had been disabled by a jumper. :-P Yet another hurdle.
I'll check it tomorrow and run some tests.
Hey, Kevin. Is there any reason you're sticking with older Linux distros like RH9 & FC1, rather than using the newer 2.6 kernel-based distros like FC4? My own experience with SATA-based systems has been a bit spotty, even with the 2.6 kernel.
Last year, I got a system with an on-board Intel ICH5 SATA controller working with FC1 (kernel 2.4), but since then nothing short of a 2.6 kernel has worked, even with a more recent ICH5 controller. My latest attempt has been with a system that had both an ICH5 and a Marvell Hercules I on-board, and the ICH5 worked fine under FC4 and Scientific Linux 4.1 (an RHEL4 clone, which itself is pretty close to FC3). The Marvell didn't work with either system, and their proprietary Linux drivers (which I didn't want to mess with anyway) weren't available for recent Linux kernels.
I ended up adding a Promise SATA II 150 TX4, which worked fine with FC4 but not SL4. I tried initially to get an SATA 150 (not SATA II 150), but they don't seem to be available anymore. The older SATA 150 is supposed to be supported by older versions of the Linux 2.6 kernel, and I was hoping to be able to run a vanilla SL4 system with no custom kernel, for the sake of stability, but no such luck. I initially thought the SATA II 150 worked with SL4, but this was after I had set up a dual-boot SL4/FC4 system. It turns out the SATA II 150 worked under SL4 after a warm boot, having been previously been initialized by the newer kernel in FC4, but it didn't work from a cold boot of SL4. (I thought I was going crazy at first, until I figured out why sometimes it found the drives on the Promise controller and sometimes it didn't.)
The web site at http://linuxmafia.com/faq/Hardware/sata.html tells the whole sordid tale of the sad state of support for SATA controllers under Linux. It seems some (several?) hardware vendors are going to be the last ones on the planet to wake up to the Linux bandwagon and limp up onto it. Anyway, for the time being I'm recommending to the Linux users I support to avoid SATA drives/controllers if you can help it, until things settle down a bit and the drivers catch up.
On Saturday, Nov 12, 2005, at 21:10 CST, Kevin McGregor wrote:
Here's a short update on the latest with my SATA woes.
First, a correction: The distribution I originally had working was Red Hat Linux 9. After trying many distributions, some with interesting failure modes (e.g. Debian Sarge), I finally got around to Fedora Core 1 (I had to download it this afternoon!). This installs kernel 2.4.22, and it not only recognized my two SATA disks, but the existing LVM setup, too! Under the old installation (I don't recall the kernel version at the moment), I was getting disk-cache reads of ~87 MB/s and disk reads of 1.39 MB/s (as reported by hdparm -tT /dev/hde). Yes, appallingly slow, but it worked. With FC1, I get disk-cache reads of 1500 MB/s (!) and disk reads of ~57 MB/s.
After that, I had the job of getting the software RAID 1 working again, as one of the drives got out of sync. I eventually figured out I needed to use raidhotremove/raidhotadd (with no man page installed!). raidhotremove /dev/md0 /dev/hdg said the drive had already been removed, and raidhotadd /dev/md0 /dev/hdg got everything going again. W00t! Now it's happily resyncing at around 10 MB/s (est. 250 mins to completion) according to cat /proc/mdstat.
Maybe I should mention that the on-board SATA controller had been disabled by a jumper. :-P Yet another hurdle.
I'll check it tomorrow and run some tests.
up onto it. Anyway, for the time being I'm recommending to the Linux users I support to avoid SATA drives/controllers if you can help it, until things settle down a bit and the drivers catch up.
I second that motion. SATA is a nightmare on linux right now (up to and including FC4). I fought with a SiI 3112 card on and off for the past 6 months trying to get it to work with no luck. See the very relevant:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=128180
In fact, there are tons of bugzillas on problems with nearly every imaginable SATA chipset out there. Not a good sign. The most common chip, the SiI 3112, is total garbage and seems to have issues with every modern distro except Ubuntu.
If I had to do SATA right now, I'd only attempt it with Intel's onboard ICH and a very new distro. Hopefully FC5 will be better in this regard.
PS: the reason the SiI works on older distros is they used the monolithic IDE driver instead of the libata/sata_sil driver. The integrated driver works fine supposedly; the sata_sil driver has issues. Ubuntu is probably using the older method, or has some patch to work around the interrupt problem.
-
Gilles Detillieux -
Kevin McGregor -
Trevor Cordes