Well I installed 9 more of the same WD drives (for a total of 12) and the parity sync (not to mention the clearing previous to the formating) is extremely slow.

 

I'm running an avarage of 10,500 KB/sec, with an ETA of 560 minutes. My MB is in enchanced mode, what else could be happening? The two previous drives synced up at 55 KB/sec, so this doesnt make much sense. Here is the Array:

 

 

 

melechmet,

 

I have two unRaid servers with 12 PATA drives installed in each one.

 

I recently replaced each 300GB parity drive with a 400GB parity drive.

 

Each rebuild started out around 16MB/sec, peaked at 50MB/sec 2/3 of the way through and finished at 36MB/sec.

 

Each rebuild started out at approximately 8 hrs to finish and finished in approximately 4.5 hours.

 

I am using build 3.0beta2 at this time.

 

Regards,

TCIII

melechmet,

 

I have two unRaid servers with 12 PATA drives installed in each one.

 

I recently replaced each 300GB parity drive with a 400GB parity drive.

 

Each rebuild started out around 16MB/sec, peaked at 50MB/sec 2/3 of the way through and finished at 36MB/sec.

 

Each rebuild started out at approximately 8 hrs to finish and finished in approximately 4.5 hours.

 

I am using build 3.0beta2 at this time.

 

Regards,

TCIII

 

TC,

 

That's interesting,

 

I'm on the same SATA drives in Beta 4 now, when on Beta 2, I had two drives done at 55-60 KB/s, from beginning to end. Now it's 3 hours in and it's still running at 10-11 KB/s.

melechmet,

 

Tom has said that he went back to the original single processor code in version beta4 because of lockups that were being experienced in beta2.

 

So far, with beta1 and beta2, I have seen the same beginning parity check speed as with other unRaid O/S builds, but the increase to around 50GB/sec during the second half of the parity check and the final speed of 36MB/sec were only seen in the two beta builds.

 

Because of the problems that some users have experienced with beta4, I am hesitant to install it.

 

I wonder if Tom has still not worked out the bugs with PATA/SATA or all SATA combinations of drives?

 

Regards,

TCIII

Well I installed 9 more of the same WD drives (for a total of 12) and the parity sync (not to mention the clearing previous to the formating) is extremely slow.

 

I'm running an avarage of 10,500 KB/sec, with an ETA of 560 minutes. My MB is in enchanced mode, what else could be happening? The two previous drives synced up at 55 KB/sec, so this doesnt make much sense. Here is the Array:

 

 

A speed of 10,500 KB/Sec for a 12-drive array is reasonable.  The 'Estimated speed' is the rate the parity disk is being written.  During a parity-sync, we are reading 11 drives and writing 1 drive in parallel.  So the amount of data moving through your system is

 

12 x 10,500 x 1024 = 129,024,000 Million Bytes/sec.  The PCI busses are the bottleneck here.

 

What motherboard are you using?  We typically get around 13,000 KB/sec on a 12 drive IDE system with D865GLKCL m/b.

Tom,

 

I'm running that very mother board with 2 Promise Tx2 cards and 1 Tx4 card, and 1 gig of 3200 PQI ram, and a 2.8ghz P4. So I'm about 2 MB/s short of the average then, I wonder if it's my mobile rack? Thanks for the math I realize now the shared PCI bus is a bottleneck for 10 of the 12 drives.

 

Having said that, I can easily build a raid 5 on a 3ware xor card, on this very platform, in far less time... I've done it, but I know apples and oranges. I guess I just need to manage my expectations better.  Still, all this PCI bottlenecking, sorta begs the question, what's the best alternative, in terms of motherboard/ card combos? Is there a 12 port SATA onboard MB available? perhaps Tyan workstation class board? Is there a PCI-e/SATA option worth exploring? While price is important, so is performance to me- if I can shave half the time for this process, I would not mind investing in a better suited platform.

 

Bytheway, I also noticed some other strangeness. Previous to the sync, in the rather long clearing phase (about 8 hours), some drives would disappear and re-appear in the web interface. At this point, during the sync, they all seem to be stable though.

What are the models of the Tx2 cards?

 

Mobile rack will not change the data transfer rate unless it's causing errors of course.  Hard to say exactly what accounts for the speed difference.  I'm writing up a document on peformance & will post soon to the website.

 

Regarding raid-5 cards - yep, they will rebuild faster because all the data is flowing internal to the card & not reaching the pci bus.  A 12-drive h/w raid card is pretty expensive, but for many apps, they are a better solution than unRAID & we've always said that.  If you're using a h/w raid card in a server, should also have multiple GigE connections as well, or else all that performance is pretty much wasted.

 

If you built an unRAID system around a m/b with multiple external PCI buses you could certainly approach the theoretical parity sync/check limit.  We've never really explored this, though, because we never viewed parity sync/check or even disk rebuild times to be that big of an issue.  And since there's still a single parity disk, write peformance would not impove anyway.

 

Agreed 'clearing' time is a pain & we plan to improve this in a future release.

 

Interesting observation regarding drives disappearing and reappearing during the clear process.  I'll look into that.

 

 

Tom,

 

I'm running 1 SATA 300 TX2 and 2 SATA 300 TX4's along with the 2 on board SATAs.

 

Well it's looking like it's going to be 10 hours on the dot for the sync (10% per hour), which amounts to about 19 hours all together to get my 12 Disk SATA array online; I've added the first 3 drives clear/sync and the 8 hour clearing cycle.

 

I'm sorry to bring up the XOR Raid, it really is apples and oranges as you rightfully explain. Both technologies obviously have their strengths and weaknesses.

 

In terms of errors encountered vis-a-vis the mobile rack, would they be listed in the web management utility? (if so I have 0 error at 80% sync now)

 

Now here is an observation- On Beta 2, I was able to sync two drives with the parity at 55-60 MB/s; one of those drives is hanging off of the SATA TX2. Assuming for a moment that there is no difference between Beta 2 & Beta 4 for this functionality, perhaps it's worthwhile to sync the drives in a serial rather than parallel process? e.g., sync 2 disks at a time (thus achieving high throughput), until all of them are done. Does that make any sense?

Never tried running more than 8 SATA drives via PCI controllers - apparantly it works... though since you have 10 drive on a single PCI bus, that would probably account for slower than normal parity sync speed.

 

No prob re: h/w xor.  I'm glad it gets brought up every now and then because people really should choose the correct solution for their situation.

 

Yes if errors were occurring you'd see the error counters move.

 

Remember syncing only 2 drives is going to go pretty fast.  BTW, a typical m/b has at least 2 PCI buses: one that the PCI connectors are attached to, and one "internal" in the southbridge chip (for the on-board IDE/SATA controllers).

 

Your idea of incremental parity sync is pretty clever - let me think about that - it might result in being faster overall.  The killer in disk systems is "missing revs (revolutions)".  When you ask for a particular sector on a disk, you have to wait for it to rotate underneath the r/w head.  So say we're sequentially reading a disk for parity sync purposes.  Since the PCI bus is saturated, at some point the on-disk buffer is going to fill up and reading from disk will stop.  Eventually the buffer drains a bit and the disk can start reading again.  But by now it might have to wait for a full disk revolution for the next sector to get under the r/w head.  This is "lost" time that results in decreased performance.  Your idea would prevent this from happening, though we'd have to be doing read/modify/write of parity all the time - might be a wash.

Your idea of incremental parity sync is pretty clever - let me think about that - it might result in being faster overall.  The killer in disk systems is "missing revs (revolutions)".  When you ask for a particular sector on a disk, you have to wait for it to rotate underneath the r/w head.  So say we're sequentially reading a disk for parity sync purposes.  Since the PCI bus is saturated, at some point the on-disk buffer is going to fill up and reading from disk will stop.  Eventually the buffer drains a bit and the disk can start reading again.  But by now it might have to wait for a full disk revolution for the next sector to get under the r/w head.  This is "lost" time that results in decreased performance.  Your idea would prevent this from happening, though we'd have to be doing read/modify/write of parity all the time - might be a wash.

Tom,

There is one other advantage of syncing parity two disks at a time. As soon as the process has finished with the first data disk it is "protected", then if a second "data" disk is processed, it too is then "protected" This would then continue untill all the disks are processed.  This might give some "partial" protection of the array earlier, even if it still takes the same time overall.

I'm having some trouble with time parity is taking. I currently have 3 finished UnRaids Unraid 2 took around 500 Minutes to complete Parity.

 

P5LD2-SE R2.0 Mobo

Promise TX2-133 2CHPair IDE Card

Promise 300TX4B 4CH Sata Controller

 

UnRaid 3 is currently is the BASIC key so is limited to 3 HDDs.  If they are all Sata the estimated time is around 400-500 Minutes, if 1 is a PATA (300gb Maxtor) on the Motherboard IDE connector the estimated time goes up to 5300 hours .  If the same IDE HDD is on the Promise controller it drops to  300 minutes.

 

Is there anything BIOS related that may be causing this?  I've tried changing the "IDE Operation Mode" to "Compatible" and to "Advanced", in "Advanced for PATA+SATA" the IDE drive isn't detected.

 

Thanks,

 

Mark.

At first it sounded like a cable issue but since you have a promise card and its working I would say your mobo is not letting the drive use a udma mode.  I would connect the hd back to the mobo, telnet into the server and run hdparm -I /dev/sd* "* being the drive identifier" and see what its running at.  Your mobo ide controller might not be supported in unraid.

 

 

At first it sounded like a cable issue but since you have a promise card and its working I would say your mobo is not letting the drive use a udma mode.  I would connect the hd back to the mobo, telnet into the server and run hdparm -I /dev/sd* "* being the drive identifier" and see what its running at.  Your mobo ide controller might not be supported in unraid.

 

Hi Erik,  I guess it could be a cable issue, I simply pulled that tray from the caddy and swapped it with a caddy bay that was on the promise controller so it would then have been on a different cable.

 

The SATA versions of those trays great but the IDE ones a a pig to fit the HDDs in, you have to scrunch up the mini IDE cable & the power connector.  My first thought was the cable inside the tray was bad, but as the same tray performed fine in a different bay that turned out not to be the case.

 

Parity is still rebuilding right now but I will try what you suggested once it finishes.  Unfortunately that'll be after I go to bed tonight so it'll need to wait until morning.

 

Thanks,

 

Mark.