Adaptec 1430SA x4 in a modified PCI-e x1 slot - works

A fine tipped soldering iron can be used to burn through the rear of an x1 slot allowing larger cards to fit and work at reduced speeds. Instead of modifying my motherboard I bought a cheap x1 riser and made sure it worked on it first. Sure enough, the 1430SA booted up and is doing a parity check without errors.

I'm getting 70,000 KB/s with 3 drives which is slower than I expected though. It could be the real world speed of the x1 slot, or maybe the riser slows it down a bit, or I might have damaged one of the data pins.  I only intend on running 2 data disks and the cache drive on it so it wouldn't affect parity speeds much. 70k KB/s for three drives works out to 102 MB/s for two drives.

A RocketRaid 2300 x1 card with the same Marvel chipset is also getting 70,000 KB/s. It must be hitting real world x1 slot limit then because the Marvel chipset is faster than 250 MB/s. I'd use this RocketRaid cardbut it overwrites sector 8 on attached disks if they aren't part of its raid array. I haven't been able to find out what exactly is stored on that early drive sector. Parity checks, with the parity drive on the motherboard controller, complete with any errors in the data for what its worth. I'm still concerned it could potentially be mucking up partition information.

edit: title change

A fine tipped soldering iron can be used to burn through the rear of an x1 slot allowing larger cards to fit and work at reduced speeds. Instead of modifying my motherboard I bought a cheap x1 riser and made sure it worked on it first. Sure enough, the 1430SA booted up and is doing a parity check without errors.

 

I'm getting 70,000 KB/s with 3 drives which is slower than I expected though. It could be the real world speed of the x1 slot, or maybe the riser slows it down a bit, or I might have damaged one of the data pins.  I only intend on running 2 data disks and the cache drive on it so it wouldn't affect parity speeds much. 70k KB/s for three drives works out to 102 MB/s for two drives.

 

A RocketRaid 2300 x1 card with the same Marvel chipset is also getting 70,000 KB/s. It must be hitting real world x1 slot limit then because the Marvel chipset is faster than 250 MB/s. I'd use this RocketRaid cardbut it overwrites sector 8 on attached disks if they aren't part of its raid array. I haven't been able to find out what exactly is stored on that early drive sector. Parity checks, with the parity drive on the motherboard controller, complete with any errors in the data for what its worth. I'm still concerned it could potentially be mucking up partition information.

The partition information on the disks in unRAID is all in the MBR (all in the first sector, sector 0, occupying the first 512 bytes of the disk)

The first "partition" starts on the first whole cylinder,  on most disks there are 63 sectors per track, so the sectors 1 through 62 are empty and un-used.  In fact, they are not even part of parity calcs, since they are zeroed on all disks and parity is currently only being calculated on the reiserfs partition from sector 63 onward.  Writing to sector 8 would do nothing to the reiserfs on the first partition as it would just be writing to an un-used area of the disk.

I learned a lot about what was being used, and what was not when I started experimenting with a new Verify-but-Do-Not-Correct parity feature in the latest 4.5-beta4 release).  (the feature it is not yet accessible from the web-interface, but does exist if you know the super-secret-handshake and password ) 

I purposely wanted to put a parity error on one of my disks where it would not affect me on a real crash if I were to have one.  When I tried messing with a byte in the third block on the disk, the change went un-noticed.  Parity checks did not find it, or report it, or correct it. (That's when I learned that currently parity calcs start on the first partition)

I subsequently learned that the first 64K of each reiserfs on our data disks is also un-used, as a place for boot-loaders, etc.  It was in that area I was able to change a byte (by writing directly to a physical drive when unRAID was not looking) to induce a parity error that would not affect any file and do my tests.

So, for now*, as far as I can see, rocketraid writing to sector 8 will not affect parity... (although, it might affect parity some-day, but in a way that won't likely matter other than a parity error will be detected at some point... see below)

Joe L.

Note: in correspondence with Tom I learned he is planning on changing the parity scheme to work on the entire disk at some point in the future, as the current scheme (from the first partition onward) limits the types of file-systems he can support, and he indicated a desire to support other file-systems at some future time.

Joe, what an informative post! That was incredibly helpful. I wasn't able to stumble upon that in my previous investigations.

Joe, what an informative post! That was incredibly helpful. I wasn't able to stumble upon that in my previous investigations.

As it turns out, the first non-zero byte in each of the data disks is not anywhere near sector 63.  You can try the following on any reiserfs disk and see what I am saying.  (Sector 63 starts at byte (512*63) = byte address 32256)

root@Tower:/boot/# dd if=/dev/hda count=300 | od -A d -x | head -20

0000000 0000 0000 0000 0000 0000 0000 0000 0000

*

0000448 0000 0083 0000 003f 0000 66b1 5754 0000         <-- partition bytes describing 1st partition start, end, and type

0000464 0000 0000 0000 0000 0000 0000 0000 0000

*

0000496 0000 0000 0000 0000 0000 0000 0000 aa55         <-- end of MBR signature bytes

0000512 0000 0000 0000 0000 0000 0000 0000 0000

*

0097792 8cd6 0aea d3dc 0066 814d 0103 0012 0000          <-- first non-zero bytes (reiserfs superblock)

0097808 0000 0000 2000 0000 0400 0000 d2a1 1abf

0097824 0384 0000 001e 0000 0000 0000 1000 03cc

0097840 03cc 0002 6552 7349 7245 4632 0073 0000

0097856 0003 0000 0005 15d6 0002 0000 6c0d 0001

0097872 0001 0000 24f0 951f 2b55 8844 b895 4828

0097888 098e 3e87 0000 0000 0000 0000 0000 0000

0097904 0000 0000 0000 0000 0000 0000 0000 0000

*

0097984 0000 0000 0000 0000 0000 0000 0001 0000

0098000 53c6 0000 5447 0000 544a 0000 5498 0000

0098016 5499 0000 54f6 0000 54f7 0000 54f9 0000

300+0 records in

300+0 records out

153600 bytes (154 kB) copied, 7.82132 s, 19.6 kB/s

The reason is described here

The reiserfs partition is divided into blocks of a fixed size. The blocks are numbered sequentially starting with block 0. There is a maximum number of 2^32 possible blocks in one partition.

 

The partition starts with the first 64k unused to leave enough room for partition labels or boot loaders. After that follows the (reiserfs) superblock.