Looks like a compelling case to stay with v5 for a server that doesn't require any of the v6 enhancements 

 

... although I confess I can't think of why 6.1.3 would be so much more CPU intensive ... especially if (as seems likely) 6.1.1 and 6.1.2 didn't have that issue.

 

 

Your "backup" server has way more horsepower then your media server. I'd swap the drives and flash devices so you can use the i3 as your main server and the lowly sempron for backup..

 

You are right and I was thinking of doing that but the media server is in a nice small case that fit's where it needs to but I may find a way.

If you're in an experimenting mood, it would be interesting to know if those CPU utilizations are significantly lower on v6.1.1 (or 6.1.2).    Based on the parity check differences others have noted, I suspect they very well may be.

 

... and, if so, that would further add to the mystery of "what happened" with 6.1.3

 

Yes, once you add an XFS drive you no longer have the option of reverting to v5.  [i'm not certain, but I believe you could actually do that and the drives would show as "unformatted" => as long as you absolutely do NOT allow it to format that, you could run a parity check.  I may test this on one of my spare "test" systems - I'll post back if I get around to doing that in the next few days  ]

 

I didn't actually look at the Dashboard during the parity check, but I suspect the CPU was indeed pretty much pegged.  Nevertheless, it seems strange that it has no problem with v5 yet is SO much slower with v6 for the exact same function.

Uhh. gary, how could you run a parity check if the 2 XFS are recognized as unformatted and would therefore be assumed as "missing" by unRAID?

Unformatted is not the same as 'missing'.  Missing means that the drive could not be seen and such drives means that a parity check cannot be carried out.  Unformatted means that the drive was seen, but it could not be mounted for some reason (e.g. file system corruption or an unrecognised file system type).  An 'unformatted' drive is still include in a parity check as that works at the physical sector level so does not care about file systems.

 

 

If you're in an experimenting mood, it would be interesting to know if those CPU utilizations are significantly lower on v6.1.1 (or 6.1.2).    Based on the parity check differences others have noted, I suspect they very well may be.

 

... and, if so, that would further add to the mystery of "what happened" with 6.1.3

 

Ok this is odd..

I didn't do a full parity check.. but enough to get a sense of CPU usage etc.

This was done with the web GUI in active window.

 

v5:

1.2% to 2.4%

with a refresh of GUI 27%

ram - 58 MB

web GUI says 52 MB/S and 352 minutes (usually takes 4.5 hrs give or take)

 

v6.1.3

80% to 85%

with GUI closed 74%

ram 87 MB

Web GUI says 85 MB/S (estimates 3 hrs)

 

I don't have time right now to do a full check or to mess with versions < 6.1.3

But just look at the CPU usage up to 85% with web GUI active.. compared to 2.4% with v5.

If I believe the estimate and MB/S  v6 should be faster doing a parity check..

I think I may try a full check with v6, just need to be done before my wife wants to watch here TV shows later today, the Voice etc..

 

I'll post the results to see if it really is faster on my server.

I have no add on SATA cards on an intel NIC and just the basic UnRaid with unMenu in v5 and Preclear and Powerdown in both v5 and v6.

I did a full parity check (non correcting) with v6.1.3 and I was surprised to find that it actually was faster than with v5 .

 

v6

completed in 3 hrs. / 18 min. / 48 seconds

CPU% 68% to 78%

avg speed 83.9 MB/s

 

any refresh on the web GUI kicks the CPU up to 93% to 100%

 

v5

it takes 4.5 hrs more or less

CPU% 1.2 to 3.4%

speed 53.4 MB/s

 

So at least on my system #1 the parity speed is faster but the CPU hit is big..

It's no wonder there are problems with single core CPUs and there are problems with the web GUI.

You really can't do anything while a parity check is in progress and I imagine if I were to do a correcting check the CPU usage would go up.

 

I'm just wondering is it worth replacing my CPU or just upgrade the whole system $$$, which I'd like to do but $$$, new MB, CPU & Case small enough to fit.

I do love the IPMI on my backup system.

 

... I imagine if I were to do a correcting check the CPU usage would go up.

 

I doubt it would change at all => the only difference between the two is that any identified errors are corrected ... a VERY tiny amount of additional "work".