I have an old box that was running 2006.1 Gentoo that I recently converted to an Ubuntu 6.10 LAMP-right-off-the-disc web server. Was time to try something new and it's working surprisingly well, but I'm not sure I'll stick with it.

I did this right as I purchased a PCI SATA controller:
http://www.syba.com/product/43/02/05/index.html
...and two Seagate 7200.10 ST3320620AS 320GB drives.

The problem I'm about to describe happened both on the Gentoo installation before I wiped it and on the new installation.

The controller runs a sil3114 chip that is (mostly, no TCQ/NCQ) supported by libata. I've read good things about it being a cheap (~$20) way to get lots of storage:
http://blogs.sun.com/PlasticPixel/en...multi_terabyte

The goal was a simple software RAID1. I ran into problems immediately because the array was constantly out of sync after rebooting. Heavy writes to it were also breaking it down. I found out the problem is not with the array, but with the the SATA link itself.

Just updated the card's BIOS to the latest non-RAID version (as in the zfs article above). While doing so from a Windows box, I formatted NTFS and ran some 8-10 GB music transfers to both drives. Worked perfectly. I also ran Seagate diagnostics on them extensively and they passed with flying colors.

Putting the setup back in the Linux box, I'm trying to just format each drive with ext3 and at least get that working before moving on to RAID. The problem is, under heavy write operations, I get this:

$ rsync -av /oldIDEspace /newSATAspace
... copy 1 GB or so ...
[42950850.170000] EXT3-fs error (device sda1): ext3_new_block: Allocating block in system zone - blocks from 32636932, length 1
[42950850.190000] Aborting journal on device sda1.
[42950850.220000] ext3_abort called.
[42950850.250000] EXT3-fs error (device sda1): ext3_journal_start_sb: Detected aborted journal
[42950850.280000] Remounting filesystem read-only
[42950850.310000] EXT3-fs error (device sda1): ext3_free_blocks: Freeing blocks in system zones - Block = 32636932, count = 1
[42950850.340000] EXT3-fs error (device sda1) in ext3_free_blocks_sb: Journal has aborted
[42950850.420000] __journal_remove_journal_head: freeing b_committed_data
[42950850.420000] __journal_remove_journal_head: freeing b_committed_data


Youch. This is consistent across both drives. fsck will subsequently further mess up the filesystem. I also tried formatting with Reiser. With Reiser the copy finishes without error, but then on reboot fsck finds the block bitmaps out of sync and the file system is subsequently hosed. Other similar problems occurred with XFS as well. I'd like to use ext3 though.

Googling around for this has produced mixed results. I'm sure I must be omitting some necessary step, considering the system is old and I'm putting newfangled hardware in it. Otherwise it's some foulplay between this card and sata_sil/libata and/or this card and my hardware.

I'd like to get this working if at all possible. I'm not in the spirit of cycling through SATA controllers until I find one that works. Thanks for any tips/suggestions to try. This one is a bit too much for me.

More info on the system to come as needed. Here are some basics:

MSI KT3 Ultra
http://www.msicomputer.com/product/d...odel=KT3_Ultra

kernel 2.6.17.10

00:00.0 Host bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333]
00:01.0 PCI bridge: VIA Technologies, Inc. VT8366/A/7 [Apollo KT266/A/333 AGP]
00:05.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller (rev 02)
00:08.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8169 Gigabit Ethernet (rev 10)
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8233A ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
00:11.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 23)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 40)
01:00.0 VGA compatible controller: nVidia Corporation NV11 [GeForce2 MX/MX 400] (rev b2)

1) don't do it with rsync, do it with 'copy and paste'

2) bios update wasprobably unnecessary

3) i use the same controller with kernel 2.6.17 as well, it is very well supported, that's why i bought it.

4) reccomendation

-- reboot machine

-- enter bios for raid card (f3 or f4 or whatever key it is)
-- delete all arrays listed there so all that shows is the 2 disks

-- let it reboot itself

-- go into linux, delete the software raid 1 array
-- do not format the disks yet!

-- create a new array with mdadm (/sbin/mdadm ... see the manpage for it)

-- format the ARRAY not the disks!
-- i reccomend XFS or REISERFS as the file systems. ext3 isn't so good on big disks.
-- XFS support should be built into your kernel, REISER may not be, so try XFS first, it's damn good anyway.

-- make sure the multidisk array gets mounted when you reboot...
-- edit your fstab, here's a chunk of mine.
# ----start---
/dev/md1 /mnt/s1_shared xfs defaults 2 1
# ----end-----

-- yours would probably be more like...
/dev/md0 /mnt/s0_shared xfs defaults 0 0

-- be sure that you "mkdir" to create s0_shared inside of /mnt, and chmod it to 777 -R (makes shit easier in the long run).

-- reboot to make sure it took

-- copy and paste your stuff from the IDE to the SATA array.

-- let me know what happens

Seeing as the drives to not work without being part of a RAID array, this will not work. The drives fail under heavy usage when formatted with any FS on their own. It's a matter of the SATA link not working properly.

I have not created any fakeraid arrays in the sil3114 BIOS.

rsync, cp--doesn't matter. This is clearly a deeper issue.

Ok, new thought then...

According to Seagate.com, the model number of hard drive that you posted above is a 320 GB SATA II (3G). So it's 300 megs/second -- whether burst or sustained, I don't know, and it really doesn't matter toward the point that I'm about to make.

The Silicon Image 3114 supports --only-- SATA I @ 150 megs/second.

SATA drives, at least in my experience, do not 'auto slow down' like PATA ones do.

If you put an ATA-133 drive on an ATA-66 interface, then it would just run at ATA-66. But if you put a SATA II drive on a SATA I interface, it just plum won't work.

Western Digital accomplishes backwards compatability with a jumper. On the back of WD drives, there is a jumper (in the same place you would look for 'master / slave' jumpers on optical drives of PATA HDD's) that when placed over two particular pins will force the drive into operating at the specifications of SATA I.

Seagate has a similar deal -- they have the 'how to' posted on this site...
http://www.seagate.com/ww/v/index.js...D&locale=en-US

You may have already done this though... at this point I'm almost thinking out-loud.

I do not recommend Silicon Image controllers. You get what you paid for. I recommend SATA controllers from Highpoint or 3ware. Though do not buy any Highpoint model higher than 1640.

When setting up RAID-1 through software, I suggest duplexing. Duplexing is using two controllers and each of them are using one hard drive. Then you combine them in an RAID array.

You can always try using Solaris. It is another form of Unix.

poweredbydodge, IDE hard drives do not auto slow down. It is the controller that tells the hard drive to use a different PIO/DMA setting.

-- if that were true, then Pentium 4 Extreme Ed. processors would out-perform three Clawhammer Opterons (if it were possible to run 3 processors together at one time on one board), since you could buy 3 of them for the price of one P4-X. Price is far from a true indication of a product's quality.

-- fair enough, but the point is that the controller auto negotiates that with the drive. SATA I controllers (most at least) cannot accomplish that.

What I mean, you buy crap, you get crap. Silicon Image controllers are crap.

Some SATA controllers does auto negotiate. SATA is still an open technology.

The jumpers are set to 1.5 Gbps by default. I verified this and did not change them.

I think I'm jumping on the SI sucks bandwagon. I ordered a different card. Promise TX4.

I'm considering using Solaris purely because of the magic that is ZFS. Unbelievable.

Promise controllers do not well in Linux. Hopefully it works better in Solaris.

... agreed, promise cards do not do too well, nor are they anywhere near as good of a brand as they used to be.

Do you guys have any basis for saying that about Promise cards?

According to libata's drive spec page, random Googling and miscellaneous other sources, Promise would appear to be a far better choice than Silicon Image, albeit more expensive.

On another note, while the Promise card appears to be much more stable, I'm still getting the same problem.

Sorry to be blunt, but I and poweredbydodge told you so. What I read about Promise controllers is that they use special techniques to handle multiple channels with only one channel. This is one reason why they are cheap. Highpoint controllers from model RocketRAID 1640 and lower do not. My Highpoint 370 and 372 (370 with software RAID) works well after 5 years of use.

Some Seagate SATA drives tend to not work well in Linux because of some flaw. Maxtor drives are the same. Seagate drives are picky with voltage levels and filteration. I suggest Western Digital or Hitachi hard drives. For a server, I recommend Western Digital 'Raptor' 74 GB. Their 150 GB version is actually slower than 74 GB.

Some things to consider when trouble shooting hardware:
1) How old is the the power supply?
If the power supply is a few years old and you want to use the computer as a server, I recommend getting a new power supply that has execellent sustain voltage levels, active power factor controlled, and universal voltage. The power power supply brands that I recommend are Eneramax, Seasonic, Zalman.
2) If this is a server, I recommend using ECC memory at the very least.
3) Check processor temperature with an hand held infrared sensor. Subtract about 10 to 20 degrees F depending on heatsink material, thickness, and fan. You may have to replace the processor if it still gives you any problems. Socket A processors are dumb because they do not have any temperature sensor to tell themselves that they are overheating and no ECC cache. I suggest upgrading to socket 939 or better because they a temperature sensor and ECC cache.

I do not recommend using ReiserFS for any type of computer. ReiserFS is an unreliable and unstable filesystem. I recommend using either EXT3 or XFS. JFS is a possibility, but it becomes fragmented. JFS should be used on small partitions. XFS can be used on small or large partitions. It also can work with small files if you use customized format options.

Couple of things first... The Promise card is working when I format XFS. The Syba card would not let me use XFS at all. When I tried to perform a write, dmesg would show all sorts of fs errors. As of now, though, I'm stable and working.

The problem I am experiencing with the Seagate drives is not the MOD15WRITE bug. I've read a lot about it and they work unbearably slow as opposed to not at all. Also there are no reports that my particular drives are affected.

1) Power supply is brand new
2) It is a home file server and I've no need to purchase ECC memory. memtest86 has not turned up any problems as of yet
3) The system has been running stable for a long time and I don't see myself getting the means to check the cpu temperature. The problem only occurred when I tried to SATA-ize it.

ReiserFS is not, by any means, my fs of choice. I was just trying to show that neither ext3 nor Reiser nor XFS were working.