Parity drive on PCI Sata or Mobo IDE?

Basically, I am currently running 3 750Gb sata drives (1P + 2D) on a single PCI sata card in an old P4 1.9Ghz. I have another older 750Gb IDE drive which can be connected to the mobo's IDE port (UDMA/100). What I want to test is whether it is faster to have the parity on a slower IDE drive/channel but separate from the PCI bus which should be bottlenecked by the 3 drives on it currently.

 

I prefer not to have to rebuild parity on the IDE drive so is it possible to clone the existing parity drive to the IDE drive since both are the same size? Searched the forums and it seems I can use "dd if=/dev/mdX of=/dev/sdZ1 bs=2048k" to clone the parity drive. Once cloned, I will just have to unassigned old parity drive, assign new one and use the Trust my parity method to get my array up. After that, run the parity check and see if there is any improvement in the speed.

 

Sounds feasible? 

 

Basically, I am currently running 3 750Gb sata drives (1P + 2D) on a single PCI sata card in an old P4 1.9Ghz. I have another older 750Gb IDE drive which can be connected to the mobo's IDE port (UDMA/100). What I want to test is whether it is faster to have the parity on a slower IDE drive/channel but separate from the PCI bus which should be bottlenecked by the 3 drives on it currently.

 

I prefer not to have to rebuild parity on the IDE drive so is it possible to clone the existing parity drive to the IDE drive since both are the same size? Searched the forums and it seems I can use "dd if=/dev/hdX of=/dev/sdZ1 bs=2048k" to clone the parity drive. Once cloned, I will just have to unassigned old parity drive, assign new one and use the Trust my parity method to get my array up. After that, run the parity check and see if there is any improvement in the speed.

 

Sounds feasible? 

 

Sorry but no.   There is no /dev/mdX equivalent to the parity drive.

 

You must stop the array, copy from /dev/sdX to /dev/hdY, then proceed as you described... assuming the drive is exactly the same size.  You would never copy from the first partition as you described... you need the entire drive.

If you have IDE drives, you probably have no /dev/sdX drives, unless you have an SATA controller. I re-read your post... your current drives are SATA.

 

Joe L.

Thanks Joe!    I also intend to preclear the IDE drive first before copying the parity over.

 

So in summary the steps are:

 

1. Install IDE drive on mobo IDE port

2. Run preclear script (to make sure drive is working fine)

3. Stop array

4. Use "dd if=/dev/sdX of=/dev/hdY bs=2048k" to copy parity drive

5. Unassign Sata parity drive

6. Assign IDE parity drive

7. Start array and use Trust my parity method

8. Parity check runs and I can check for any improvement in speed

9. If happy with speed, then keep IDE parity drive and convert Sata parity drive to a data drive

 

For the last step, do I need to preclear the Sata parity drive again to add it as a data drive?

 

 

For the last step, do I need to preclear the Sata parity drive again to add it as a data drive?

 

If you don't pre-clear it, then unRAID will clear it when you start the array.... but your array will be off-line for a few hours while it does it vs. a few minutes off-line if pre-cleared.

 

Joe L.

Basically, I am currently running 3 750Gb sata drives (1P + 2D) on a single PCI sata card in an old P4 1.9Ghz. I have another older 750Gb IDE drive which can be connected to the mobo's IDE port (UDMA/100). What I want to test is whether it is faster to have the parity on a slower IDE drive/channel but separate from the PCI bus which should be bottlenecked by the 3 drives on it currently.

 

This will be an interesting test. Keep in mind, the IDE drive will probably also be on the PCI bus.

What is the PCI sata controller you are using?  If it is a modern one it may have a small FIFO and you may loose the benefit of that.

If you have other P-ATA drives, do not connect them to the same cable as the parity drive, (Unless it happens to be a cache drive)

The PCI sata card I am using is this one here. Nothing great and even disables by default the write cache on my drives.   Not sure about the FIFO part...

 

PATA drive is on the cable by itself. Currently I am running a parity check before I copy the parity disk. Average speeds of about 38-40mb/s. Looks like the PCI bus has been maxed out by the 3 drives.. 

 

Will update again when I am running the parity check on the PATA drive...wish me luck! 

 

PATA drive is on the cable by itself. Currently I am running a parity check before I copy the parity disk. Average speeds of about 38-40mb/s. Looks like the PCI bus has been maxed out by the 3 drives..

 

This isn't all so bad. I have 9 drives on internal and PCIe, I get 40mb/s.

And when I do a parity check on my PCI based system with 10 data disks I get roughly 12.9MB/s 

(12.9 * 11 disks = 141.9 MB/s passing through the PCI bus, making it maxed out too.) 

Theoretical max should be 133MB/s... so I'm doing better than theory..

 

 

Looks like I shouldn't get my hopes up too high on a significant increase in performance..  

 

Let me see if my understanding of parity generation and checking is correct.

 

For parity checks, the corresponding bit is read from all drives and computed to see if it matches what is stored. This involves read operations from all drives including the parity drives. My mobo is using the 850/ICH2 chipset which has a 266MB/s connection to the memory/cpu. In theory, if I separate the 2 data drives and parity drive, the 2 data drives can hit their max read speeds of about 70MB/s each on the PCI bus while the parity drive can also hit its max read speed on the IDE channel (if not shared with the PCI bus). So I should hopefully see an increase in the parity check speed although real-world performance is usually not so perfect.

 

For parity generation, when new data is added, the new bit is written to the data disk. unRaid also reads the parity drive and re-computes the correct bit to be written back. So if the data and parity drives are on separate channels, then there will be less performance impact from any potential bottlenecks.

 

This forms the basis for my experimentation...sounds correct?

 

Looks like I shouldn't get my hopes up too high on a significant increase in performance..  

 

Let me see if my understanding of parity generation and checking is correct.

 

For parity checks, the corresponding bit is read from all drives and computed to see if it matches what is stored. This involves read operations from all drives including the parity drives. My mobo is using the 850/ICH2 chipset which has a 266MB/s connection to the memory/cpu. In theory, if I separate the 2 data drives and parity drive, the 2 data drives can hit their max read speeds of about 70MB/s each on the PCI bus while the parity drive can also hit its max read speed on the IDE channel (if not shared with the PCI bus). So I should hopefully see an increase in the parity check speed although real-world performance is usually not so perfect.

Max theoretical speed of the PCI bus is 133 MB/s, so I doubt if you'll get 140MB/s combined from 2 drives. (70MB/s each)

For parity generation, when new data is added, the new bit is written to the data disk. unRaid also reads the parity drive and re-computes the correct bit to be written back. So if the data and parity drives are on separate channels, then there will be less performance impact from any potential bottlenecks.

Almost correct...  When writing to the array the old data bit is first read from the data drive, and the old parity bit is read from the parity drive... then unRAID computes the new parity to be written based on the new data bit, and then writes to both the data and parity disks.  Before the "write" can occur, the disks must rotate at least one complete revolution to get the same sector under the write head that was just previously read.  One "bottleneck is this need to wait to get to the sector to write it after reading it.  Another, as you already mentioned, is the throughput on the PCI bus.

This forms the basis for my experimentation...sounds correct?

You were real close.

Before the "write" can occur, the disks must rotate at least one complete revolution to get the same sector under the write head that was just previously read.  One "bottleneck is this need to wait to get to the sector to write it after reading it.

Actually if the drive has write caching enabled, you do not wait for the sector to be under the drive heads.

However, reads may take priority over writes, which could eventually fill up the cache.

 

The bottleneck in this scenario is the PCI BUS.

What is the motherboard?  Perhaps there is a manual with a block diagram.

In looking at some old block diagrams of boards, it looks as thought the ICH2 chipset is hung off the PCI bus.

 

If you really want to separate the drives as you are trying. it may be time to upgrade past that class of board.

 

 

Actually if the drive has write caching enabled, you do not wait for the sector to be under the drive heads.

However, reads may take priority over writes, which could eventually fill up the cache.

True... if you are only writing one sector.  But, when writing most media, we very quickly use up the 32Meg buffer as we read and write many thousands of sectors.  In the same way, the disk driver read-ahead buffer is also helping when reading the blocks of the "next" sector to be written,  but it too ends up way smaller than most of the files we store.  Either way, the rotational speed is still a limiting factor.

The bottleneck in this scenario is the PCI BUS.

What is the motherboard?  Perhaps there is a manual with a block diagram.

In looking at some old block diagrams of boards, it looks as thought the ICH2 chipset is hung off the PCI bus.

 

If you really want to separate the drives as you are trying. it may be time to upgrade past that class of board.

Good advice.

And when I do a parity check on my PCI based system with 10 data disks I get roughly 12.9MB/s   

(12.9 * 11 disks = 141.9 MB/s passing through the PCI bus, making it maxed out too.)   

Theoretical max should be 133MB/s... so I'm doing better than theory..

 

Well, you got 141.9 so I am hoping to get lucky too... 

 

What is the motherboard?  Perhaps there is a manual with a block diagram.

In looking at some old block diagrams of boards, it looks as thought the ICH2 chipset is hung off the PCI bus.

 

The manual can be found here (12Mb pdf file). It's an old HP x2000 server that I got from my office for 10 bucks.   The block diagram is on page 54. The PCI bridge and IDE controller appear to be separate blocks within the ICH2 hub. And from here, it states that the ICH2 hub has a 266MB/s connection to the i850 memory hub. So I am still hoping that I will somehow be able to get a performance boost by separating the data and parity drives.

 

If you really want to separate the drives as you are trying. it may be time to upgrade past that class of board.

 

I've got another old P4 3Ghz with onboard SATA and PCIe that I am ready to convert to a second unRaid server. But since I don't need the extra storage yet, I'll make do with this one for the time being.

 

Update

 

Just finished copying my parity drive to the IDE drive.

Trusted array with new parity drive and now unRaid is running a parity check.

 

The results so far:

 

Total size:	732,574,552	KB
Current position:	7,460,356	(1.0%)
Estimated speed:	50,304	KB/sec
Estimated finish:	240.2	minutes
Sync errors:	0	

 

Looks like a 10MB/s improvement...worth all the effort... 

 

It would appear to me that you got at least $10. worth of cast-off hardware...  I'll bet they paid a LOT more for it originally.

 

It is not clear from the manual if the IDE controller hangs off the PCI bus.  It does not look like it does.  You might get a lot better performance... we'll just have to wait till you do your tests.

 

Perhaps that is why I get a bit better than "theory" says I should... I'll bet the disk controllers built into my MB are not on the PCI bus either.

 

Just saw your most recent post... nice performance boot.  Yes... I'll bet you can find at least one or two visitors to this forum willing to give you $20 for your old HP x2000. (You could double the value of your $10 investment)

 

Joe L.

In that block diagram it does look like the IDE is off the ICH2 and not the PCI bus.

Other block diagrams I've seen had the ICH2 coming off the PCI bus

 

Your numbers are pretty good too.

 

not bad for $10 bucks.

Yes...I am sure they paid a lot more for it when they bought it in 2001...

 

This is one of the rare times when real-life performs better than theory...heh...

 

I'll bet you can find at least one or two visitors to this forum willing to give you $20 for your old HP x2000. (You could double the value of your $10 investment)

 

Haha...it cost me $10 but it weighed about 10kg and my car wasn't exactly parked near my office...

My only complaint (other than the weight) is that it runs on 512MB of RDRAM and it's almost impossible to find an old pair selling cheaply to upgrade the ram...

 

Parity check completed with zero errors..life is good.. 

 

Sidetrack a bit. This experiment also means that I can clone my parity drive for extra protection (manual backup). Of course if it's a 2 data drive failure then I am still screwed. But in a 2 drive (parity & data) failure, I can put in the cloned parity drive and rebuild the failed data drive.

 

My current usage of unRAID is mainly on weekends only. So if I clone my parity drive after each weekend, I should have some extra protection during the week. Not fantastic but requires minimal effort (can be scripted I believe) on my part...until we get RAID6 implemented for unRAID...

 

Parity check completed with zero errors..life is good.. 

 

Sidetrack a bit. This experiment also means that I can clone my parity drive for extra protection (manual backup). Of course if it's a 2 data drive failure then I am still screwed. But in a 2 drive (parity & data) failure, I can put in the cloned parity drive and rebuild the failed data drive.

 

My current usage of unRAID is mainly on weekends only. So if I clone my parity drive after each weekend, I should have some extra protection during the week. Not fantastic but requires minimal effort (can be scripted I believe) on my part...until we get RAID6 implemented for unRAID...

 

Not exactly true... If you lose two data drives at the same time you cannot rebuild either data drive.... no matter how many parity drive copies you make. 

 

Your extra parity drive copy is only good until you make ANY change to ANY other disk.  Then it is out of date, and if you attempt to use the older party copy, it will result in a corrupted file.

 

If you have critical files, copy them to two other drives... then you will need to lose three drives....  if really critical, make backups... ans store the backups elsewhere.

 

Joe L.

Roger that.

 

Probably gonna go with a second unRAID server to mirror my important files. Thanks Joe! 

 

Roger that.

Probably gonna go with a second unRAID server to mirror my important files. Thanks Joe! 

 

That is the way I do it,

Wake on lan to wake up.

rsync across the net.

Shutdown.

Roger that.

 

Probably gonna go with a second unRAID server to mirror my important files. Thanks Joe! 

 

That will do it, except for common hazards of fire/flood/tornado/direct-lightning-strike that would involve both servers.

That will do it, except for common hazards of fire/flood/tornado/direct-lightning-strike that would involve both servers.

 

Yup. Do any of you use a online storage solution like Backblaze to cater for such situations?

 

You may want to consider crashplan.  They have an all you can eat multiple computer plan and people have it running on UnRaid.

Family Unlimited Plan

Are you responsible for protecting more than one computer? For one low price, get unlimited storage for all of your computers under a single account.

 

 

http://www3.crashplan.com/consumer/index.html

 

Looks really great...thanks for the link! 

 

Googled halfway across the internet before realising that there's a wiki on using Crashplan with unRaid.. 

 

http://lime-technology.com/wiki/index.php/CrashPlan