I am not seeing writes to my SATA cache drive much faster than to my parity-calc'd drives (low-teens MB/sec).

 

Are other folks seeing faster speeds?

 

My syslog is attached.  I am running three separate SATA port types on my ASUS P5B-E: six from the mobo, four from a Promise TX4, and one from the additional Jmicron slot (changed to ACHI).  I am fairly sure the cache drive is on the TX4 with two of my other drives.

 

Relevant facts:

Unraid: P5B-E, underclocked Pentium D820 (down to 2.1GHz from 2.8 to reduce heat/noise/energy consumption), 1GB RAM, 4.3b6, a mix of five Seagate 300GB and four WD 1TB SATA2 5400 drives, Intel Pro/1000 PCI GigE - 119W at idle, 161W w/all nine drives spinning (would be better but I have a fairly inefficient PSU and a graphics card installed)

Network: Dlink GigE w/Cat5E

Read speeds are ~25MB/sec, capped by the write speed of my local XP SP2 IDE system

 

I have a need for the 300GB drive elsewhere and will move it there if being used as a cache drive has no benefit.

 

 

Thanks,

Bill

 

UPDATE: I did a direct copy from parity calc'd drive to the cache drive w/in Linux and got more like 30MB/sec, so there is something else going on here.  One thing I have noticed is that my client machine's network speed craps out if anything else is using the CPU, so perhaps that is it.  Sigh.  More experimentation needed.  Regardless, if I can't get the speed to increase, I'll pull out the cache drive.

Did you check the parameters with hdparm?  How about a test with hdparm -tT?

Bill, I don't see any serious performance problems, or disk errors, but I think you may have misunderstood how the Cache drive is used.  Most importantly though, it looks to me as if the 2 new drives you added FAILED TO CLEAR, but were formatted and mounted anyway!!!  I imagine I don't have to explain the ramifications of that.  Unless I'm wrong here (and I don't see how) or those 2 new drives were already completely cleared, your parity is invalid, and you are not protected!  If a drive were to fail and you tried to rebuild it, it would probably be corrupted.  You can do a quick test by starting a parity check, but if it shows many errors, I would cancel it and manually rebuild the parity drive, by un-assigning it, starting and stopping the array, and re-assigning it, and starting the array.  This looks like something Tom should look at.

 

As to the Cache drive, you don't appear to have User Shares enabled.  The Cache drive is only written to when it has been configured as part of a User Share, and you then write to that User Share.  The write will go to the Cache drive, bypassing the parity process, and be much faster.  The Cache drive is not used at all for direct writes to the Disks.  You might as well use the 300MB elsewhere.

 

If you still want to use it, I imagine the experts here can help you export /dev/sdc1, so that it would be visible and writable from other machines.

OK, I will run a parity when I get home.  Nothing odd happened when I dropped in the drives and started it up.

 

Re: user shares - I know they are not enabled.  I was just trying to do a rough speed test before moving forward - if writing to the cache drive is 2-2.5X the speed of writing to a parity-protected drive, I'll use it.  Otherwise, I won't.

 

bubbaQ - I did a quick sweep with hdparm and found that the parity drive returned a speed roughly 3X that of a parity-protected drive (something like 75MB/sec vs. 25MB/sec) - this was for the second of the two tests (the first looks like a cache test as it was stoopid fast - like 1000MB/sec).

 

 

Bill

the parity drive returned a speed roughly 3X that of a parity-protected drive

If the parity drive is a 1TB WD vs the drive of a 300GB unit, the speed difference will be dramatic.

Other then that with an hdparm -t which is just a read test each 1TB SATA drive should be approx the same speed returned. parity or not.

For a real write/throughput test do a test with bonnie or bonnie++.

I have been using dvd iso transfers from one box to another or within a box to eliminate any cache memory concerns.

 

 

Bill

...

Most importantly though, it looks to me as if the 2 new drives you added FAILED TO CLEAR, but were formatted and mounted anyway!!!  I imagine I don't have to explain the ramifications of that.  Unless I'm wrong here (and I don't see how) or those 2 new drives were already completely cleared, your parity is invalid, and you are not protected!  If a drive were to fail and you tried to rebuild it, it would probably be corrupted.  You can do a quick test by starting a parity check, but if it shows many errors, I would cancel it and manually rebuild the parity drive, by un-assigning it, starting and stopping the array, and re-assigning it, and starting the array.  This looks like something Tom should look at.

 

Yes indeed this is a serious bug, introduced in 4.3-beta4.  This is fixed in 4.3 "final" which will be released just as soon as we verify the fix.  Good catch RobJ!  I owe you a beer or something 

I'm glad I read this thread. I added my 7th data disk recently and it formated itself but it didn't clear. I didn't think much of it (although I did note it in another thread and no one mentioned anything so I thought it was ok).

 

I'm re-building parity right now. It looks like because of this, for the last week my entire array was unprotected 

I'm glad I read this thread. I added my 7th data disk recently and it formated itself but it didn't clear. I didn't think much of it (although I did note it in another thread and no one mentioned anything so I thought it was ok).

 

I'm re-building parity right now. It looks like because of this, for the last week my entire array was unprotected 

After reading this thread I decided to verify my own parity.  I also have added/upgraded drives recently.  In my case, the last operation was replacing an existing 250 Gig drive drive with a larger 750 Gig drive.  Apparently, that process fixed any parity issues. 

 

In any case, my parity check ran overnight, and it found no errors. (a good thing)

 

Joe L.

If array integrity is important to you, I recommend that you always run a full parity check before and after doing any type of disk maintenance (upgrading, adding new, etc.).  (With a failed disk replacement skip the before check but do it after.) 

 

The before check will cause each and every sector on each and every disk to be read.  This gives the SMART monitoring features of your hard drives the opportunity to take corrective action if needed to remap marginal sectors.  If you have any actual read errors (i.e., bad sectors), unRAID will fix them while the array is protected.  The before check also confirms that you are starting your upgrade process from a known good state.  If you get errors in your before parity check, I'd recommend capturing a syslog before rebooting (see below) and running parity check AGAIN to confirm all is well before proceeding!

 

The after check will confirm that any clearing took place and that your array is again protected.  It (again) causes each and every sector to be read.  Errors in brand new disks are not uncommon, and this operation may be the first time that the SMART system will have an opportunity to read each and every sector (unless you have done some burn-in testing).

 

If you get sync errors, you need to capture a syslog and post it here BEFORE REBOOTING.  Follow the troubleshooting link in my sig for instructions.  You may have found a bug (rare but that was the case here), and will be the hero for having found it!  The log is the only source of information that will help you know the root cause.  If you reboot - your opportunity is lost, and will be left wondering if your system is suspect in some way.  The syslog lives on a ramdisk and is cleared on every reboot.

 

Final note, the parity check process WILL correct parity, so even if you get a bunch of parity sync errors reported, the errors should have already been corrected by the time the check is complete.  This is common after a power off event (non-clean shutdown).  I recommend running ANOTHER parity check afterwards to make sure you get a 100% clean parity check.  Only then should you feel your unRAID protection is fully in place.

 

I had this issue sometime ago, and even started a thread on it.

I ran parity and had no errors.  Am I at risk with having not cleared the drives yet the parity is OK?

 

Back to my original question, I still can't find a reason why writing to a parity-protected drive is no slower than writing to one outside the array.  But given that it seems to be the case, I will pop out the 300GB drive and use it elsewhere.

 

 

Bill

I ran parity and had no errors.  Am I at risk with having not cleared the drives yet the parity is OK?

 

Back to my original question, I still can't find a reason why writing to a parity-protected drive is no slower than writing to one outside the array.  But given that it seems to be the case, I will pop out the 300GB drive and use it elsewhere.

 

 

Bill

 

If parity passed then you should be good. Your drive probably came with zeros written to it already. Now, if the drive came with 1's or something written to it then that when you'd have some errors and a problem with parity.

 

Question on your Seagate drive... did you remove the jumper? It comes with a jumper that limits the speed to 150 instead of 300.

Thanks.

 

I don't remember if I took off the jumpers when I first installed them last year, but I probably did.  Regardless, I think I would be happy with 188MB/sec. 

 

I'll check the next time I shut down the system.

 

 

Bill

I ran parity and had no errors.  Am I at risk with having not cleared the drives yet the parity is OK?

 

If you have completed a parity check, then parity is valid and everything is fine.  I don't understand why you did not see a lot of parity errors though.  The new drives must have been completely cleared from the factory.

 

Back to my original question, I still can't find a reason why writing to a parity-protected drive is no slower than writing to one outside the array.  But given that it seems to be the case, I will pop out the 300GB drive and use it elsewhere.

 

Bill, I am probably not understanding something, but didn't you say that writing to the cache drive was at 30MB/sec?  That sounds about right, and is almost 3 times the speed of writing to a parity protected drive.

 

As to the Seagate jumpers, I did notice the possibility that you had jumpers still installed, but I did not think it mattered, partly from a bad assumption on my part.  The cache drive is the only drive that was connected to a port that supported 3.0 Gbps, and it did appear to have the jumper still installed (SATA link up speed of 1.5Gbps), but since it is connected through the PCI bus, removing the jumper won't make any difference (150 2-way is already faster than 133 1-way), so I didn't mention it.

 

The rest of your Seagates were connected to ports that I did not think (wrongly!) supported full SATA speed.  I did not think that your ICH6 supported ahci and 3.0 Gbps, because I thought AHCI did not arrive until ICH8 or ICH9.  I (now) decided to double-check that on other syslogs from ICH6 boards, and discovered that ICH6 *does* support both ahci and 3.0 Gbps, on all 6 ports.  It appears that yours are not configured correctly (perhaps in an IDE or emulation mode?), so I would recommend checking for an AHCI or native SATA mode in your BIOS menus, on the next reboot.  Once they are re-configured, then the jumpers *will* matter, and it will be clear in your next syslog what SATA link up speed they are connecting at.

 

By the way, you aren't using the 2 ports that are currently the fastest (until the ICH6 ports are re-configured).  The 2 JMB SATA ports are already set for AHCI and support 3.0 Gbps, but show as unused.  If you can't change the BIOS settings, I would move the parity drive to one of the JMB ports, and remove any jumper.

 

Edit note:  some of this is discussed on the new Improving unRAID Performance page.

Excellent info - much appreciated.

 

 

Cheers,

Bill