unRAID OS Version:

 

6.0-beta10a

 

Description:

 

Upon completion of a Parity Check, there are a couple of lines (the second being new in version 6).

 

The first line states: Last checked on ..., finding 0 errors.

 

The second line states: > Duration: ..., Average speed: ...

 

I'm seeing the average speed not matching the size / duration.

 

How to reproduce:

 

I believe this will happen any time the duration of a parity check exceeds one day.

 

Expected results:

 

In my case I expected to see a number near 30MB/s for my 4TB parity check with duration about 1 day, 14 hours.

 

Actual results:

 

Instead I saw an average speed reported near 80MB/s, a quick check shows that it's consistent with losing the day off the duration (i.e. just 14 hours was used in the calculation).

 

Other information:

 

Screen capture attached.

 

I've captured the syslog for the session pictured, but doubt it will be necessary to fix this problem.

what you should also look into is why it takes 38 hours!?

 

My 3TB array takes around 10 hours to complete.

Hi Mr Hexen . . . I figured that was coming.

 

I'm still working on this new server.  It was the first time I did a parity check of all 5 drives.

 

Yes it's slow, I'll probably be getting a more modern PC to host this array (this one is over 7 years old).

 

I've got a bottleneck apparently on the motherboard, I'm only seeing half the bandwidth I should be seeing even with just a PCIe x1 card.  So that would bring it to 19 hours when that's gone.  There should be more room for improvement after that.

What are your system specs?

Probably best if I don't clutter this Defect Report with my system specs.  Unless you're just asking for the host PC specs, that I can easily answer:

 

http://www.newegg.com/Product/Product.aspx?Item=N82E16883114030

 

I've maxed the RAM out at 2GB.

 

I bought it 7+ years ago for under $250, and recently replaced it, so I thought I'd see how well it works as host for an unRAID server.  So far it's not cutting it, seems like I'm hitting PCI bus bottlenecks.

 

It's not my first unRAID server, my old one I've had for over 3 years; it's at 64TB.

 

I've got another data point:

 

Duration: 1 day, 8 hours, 49 minutes, 13 seconds. Average speed: 126.0 MB/sec

 

This result is consistent with the theory that the number of days is not being considered in the average speed calculation.

 

Just to be clear: this "defect" in no way causes me a problem.  I only report it because, if I had built and/or was maintaining unRAID, I would want to know about this problem.  I imagine there are much more important things to fix before this one.  I've been using unRAID for over three years and this is the first defect I've encountered worth reporting.  Suffice it to say I'm a happy customer.

Definitely an interesting issue.    Hard for most of us to replicate, as I don't think very many systems take over a day to do a parity check !!

 

It'd be useful to see your complete hardware specs -- motherboard, CPU, add-in SATA cards, etc.

 

Hi Gary, I understand that system specifications usually matter when it comes to reproducing a defect.

 

In this case I doubt they matter . . . there's likely one line of code in the average speed computation that's using the time *after* the days are removed instead of *before*.

 

As mentioned earlier in this thread, this is my second unRAID server and is a work in progress.  Currently the host PC is an eMachines W3609 (over 7 years old).  I recently replaced it and thought I'd see how well it would work as an unRAID server (not so well, PCI bus bottleneck apparently).

 

I've tried a couple of different eSATA cards so far (that have worked):

 

- StarTech PEXESAT32

- HiPoint RR642L

 

The five 4TB drives are in a Sans Digital TR5M+B eSATA JBOD enclosure.  Even with all five drives sharing one 3Gb/s eSATA connection (like during a parity sync/check) I should still get ~60MB/s throughput per drive, assuming the drives can do it (no problem there) and the controller/motherboard can keep up (hitting a problem there unfortunately).

 

But the above is moot as of earlier today when I ordered this as the new host PC, for $225 out the door:

 

http://www.amazon.com/Lenovo-ThinkServer-70A4000HUX-i3-4130-Computer/dp/B00F6EK9J2

 

As I realize that people here *are* interested on other people's builds, I'll probably start a thread in the UCD forum for this server build.  I *am* trying to achieve decent parity check/sync times, since if a parity rebuild were to become necessary (and it will!), the entire time the rebuild is happening the array is vulnerable to a second drive failure, losing both the first and second failed drive's contents.  So shorter is better as far as how long the rebuild takes.

I suspect the port expander in the Sans Digital box, coupled with possible bus bottlenecks with the add-in card is what's causing your very slow speeds.

 

I agree it's essentially irrelevant at this point, since you're got some dramatically better hardware on the way 

 

Thanks for the suggestions Gary.

 

Hopefully I can rule out problems in the enclosure with some testing on a different PC.  Or just see if the problem goes away when I fix everything else!

 

I have an eSATA 6G version of that enclosure also, but it didn't want to play with the old setup; I'm hoping *that* problem will also go away with the new host.

 

Then even with all five drives going I should still have up to 120MB/s throughput per drive.  That'll allow (assuming the drives are up to it) a parity check or sync to finish in under 10 hours.  I'd be happy with that.

BTW, did you send Tom a note advising him of this bug?    I suspect it's VERY rarely encountered ... but it's likely a simple fix.

 

Incidentally, do you know if it's also true with older versions (e.g. v5) ??

 

When a parity check finishes in v5, you can click the Log button in the top right corner of the Web GUI and it will show how many seconds the check took.    It'd be interesting to know if this is correct on your system.    If you've got a bunch of "stuff" configured (VMs, Dockers, etc.) you may not want to roll back to v5 to try that -- but if it's just a basic NAS it'd be easy to do.

 

That same Log button is on the v6 GUI as well -- it'd be interesting to know if the number of seconds shown is correct (i.e. if this is just a computational issue with the display, or if the actual counter is incorrect ... i.e. wrapping at 24 hours)

 

 

 

I can send Tom a note . . . didn't realize that was part of the process.

 

The duration in seconds reported in the log *is* correct.

 

I can send Tom a note . . . didn't realize that was part of the process.

 

The duration in seconds reported in the log *is* correct.

 

I'll send him a note and point him to this thread.    Very interesting that the seconds are reported correctly -- clearly that simply means there's an error in the display logic, NOT in the actual timing of the check.    But that error is carried forward into the average speed computation as well -- so clearly it should be fixed.

 

Thanks Gary.

 

Note that the "Duration" displayed on the web GUI *is* correct, only the "Average speed" drops the days part.

Thanks Gary.

 

Note that the "Duration" displayed on the web GUI *is* correct, only the "Average speed" drops the days part.

 

Ahh ... I'd forgotten that => it's clear on the display you included in your first post, I was just focused on the "drops a day" part and forgot that it only applied to the speed computation.    I suspect this is a very simple fix ... but I also suspect you're the first person who's noticed it, as it's very unusual for a parity check to take over 24 hours.

 

I asked Tom to look at this thread, so he should see the details here 

I appreciate your help.