did you let it finish completely?

No. It will take 25 hours to complete. On the 245 CPU it instantly goes to 75MB/s and stays roughly around that speed and therefore I think the 42MB/s will not get any better.

Hate to say it, but let it finish.  I too was seeing slow parity progress (20-40MB/s) in the first 3-ish% ... then I let it finish overnight and final speed was on the order of 95MB/sec ... tim was 6.x hours and not the initial 25+hours it was estimating.

 

Afterall, you aren't hurting anything by letting it complete.

It's currently at 12% and its still at 42MB/s.

In any case, I would prefer it to NOT correct, as once parity is modified it is not possible to get back to where it was... (if checked you are always trusting your data disks, even potentially if they have failed)

 

I agree.  I'm sure that part way through the 5.0 development cycle, the default was set to 'Not Correct' but Tom decided to change it back.

 

I'm very wary of the possibility that I boot the machine up and, before I have any chance for user interaction, it is starting to overwrite my parity data.  I know that it has been stated that it is nearly always the parity disk which is wrong, but I'm afraid of falling into the few percent gap where that is not the case.  I believe that the user should always have overriding control of any correction procedure.

In any case, I would prefer it to NOT correct, as once parity is modified it is not possible to get back to where it was... (if checked you are always trusting your data disks, even potentially if they have failed)

 

I agree.  I'm sure that part way through the 5.0 development cycle, the default was set to 'Not Correct' but Tom decided to change it back.

 

I'm very wary of the possibility that I boot the machine up and, before I have any chance for user interaction, it is starting to overwrite my parity data.  I know that it has been stated that it is nearly always the parity disk which is wrong, but I'm afraid of falling into the few percent gap where that is not the case.  I believe that the user should always have overriding control of any correction procedure.

 

I agree too.  And thanks Joe for confirming.  We should all ask that Tom change that back so that the box is not checked and we have the option to accept the corrections or not.

I'm very wary of the possibility that I boot the machine up and, before I have any chance for user interaction, it is starting to overwrite my parity data.  I know that it has been stated that it is nearly always the parity disk which is wrong, but I'm afraid of falling into the few percent gap where that is not the case.  I believe that the user should always have overriding control of any correction procedure.

 

+1

 

In my eyes, no OS should EVER write/modify my data without me expressly confirming it. I know parity isn't technically my data, but if I'm relying on it to rebuild a disk in case of failure, ultimately it is.

 

Its definitely a matter of opinion for which is best, since as you said its nearly always the parity that's wrong, but its possible its the data disk. Maybe an option of "if parity check has XX amount of errors, take array offline and e-mail admin". (see what I did there, pushing for e-mail notifications integrated) This way if there are issues, the array is stopped to reduce the likelihood of failure before the user can check it out.

 

We should all ask that Tom change that back so that the box is not checked and we have the option to accept the corrections or not.

 

Or better yet, make the option persistent. Just write another small config file to /boot/config with the setting "CORRECTING=no/yes". This way all users get it the way they wish.

 

In my eyes, no OS should EVER write/modify my data without me expressly confirming it. I know parity isn't technically my data, but if I'm relying on it to rebuild a disk in case of failure, ultimately it is.

 

 

Said perfectly.

I just tired to uncheck the box, then hit Refresh, and it was checked again.  it looks like you cannot uncheck at all.

 

I guess we all better pray that this does't bit us on the back side.

 

Tom - please correct this in  the next release, and for sure in the Final.

You can uncheck it. Just uncheck it and then click start parity and the goto syslog and it will say NOCORRECT.

You can uncheck it. Just uncheck it and then click start parity and the goto syslog and it will say NOCORRECT.

 

I'm aware of the manual process.  However, I have my config setup to it runs the Parity check monthly (like most do), which starts automatically and it will write the correction automatically.  You cannot uncheck the box and expect it to remain unchecked, which is my concern and therefore the request for Tom to change this for future releases.

You can uncheck it. Just uncheck it and then click start parity and the goto syslog and it will say NOCORRECT.

 

I'm aware of the manual process.  However, I have my config setup to it runs the Parity check monthly (like most do), which starts automatically and it will write the correction automatically.  You cannot uncheck the box and expect it to remain unchecked, which is my concern and therefore the request for Tom to change this for future releases.

The monthly parity check set up via cron is usually a NOCORRECT check (unless you specifically requested it to be a correcting sync).  It has absolutely nothing to do with the checkbox on the main unRAID screen.  (It does not even know the main screen exists, never mind a checkbox on it)

Thanks Joe!  I didn't know that, and feel much better now. 

 

I haven't changed it so this is good.

 

My expectation is that if the monthly check runs and IF there are errors, I will be given the choice to review and decide what to do.  I hope it works that way.

 

I haven't had any errors in a long time (knock on wood) so I have no experience and don't know what to expect.

 

My CPU is going on slowest speed, and I have disabled modprobe powernow-k8 in my go file!

 

How can I change this? having  slowest speed i got very slow DL from usenet :-(

 

EDIT

 

SOLVED: used modprobe -r  powernow-k8 in the go file ;-)

 

 

//Peter

Thanks again Tom for your hard work and dedication. I also work in a position where its hard to please many people, at least at the same time anyways. I'd also like to thank the unraid community for helping Tom when he's not around, developing plugins and doing support for this product it really makes this a complete product.

 

 

So far I've had to replace a bad disk So I did a preclear, disk swap/rebuild, and parity check and no issues came up so pretty much 3 days worth of controller/disk activity. Everything worked better then 4.7.  The speed is way up there now, with the betas it would top out at 50,000KB Current 34,575,256 (1.8%) Speed 107,752 KB/sec

 

The syslog service restarted on its own but I'm running plugins so one of them might have caused it.

syslog.1

Sep 29 03:31:29 Fileserver02 logger: ./TV/

Sep 29 03:31:29 Fileserver02 logger: .d..t...... TV/

Sep 29 03:31:29 Fileserver02 logger: skipping WDM/

Sep 29 03:31:29 Fileserver02 logger: skipping router/

Sep 29 03:31:29 Fileserver02 logger: skipping router1/

Sep 29 03:31:29 Fileserver02 logger: skipping router2/

Sep 29 03:31:29 Fileserver02 logger: skipping tmp/

Sep 29 03:31:29 Fileserver02 logger: mover finished

 

syslog

Sep 29 04:40:01 Fileserver02 syslogd 1.4.1: restart.

Sep 29 08:34:40 Fileserver02 kernel: mdcmd (24): check NOCORRECT

Sep 29 08:34:40 Fileserver02 kernel: md: recovery thread woken up ...

Sep 29 08:34:40 Fileserver02 kernel: md: recovery thread checking parity..

 

 

 

You can uncheck it. Just uncheck it and then click start parity and the goto syslog and it will say NOCORRECT.

 

This is what I did and it worked properly.

 

I agree that the default should be no correct.

 

My speeds writing to the array are pretty slow; 20 to 30 MBps while on the same network I am getting 60 or so from windows box to windows box.

Installed RC8a and SMB is much snappier from Windows Vista - file lists are updated !!! much !!! faster.

updated SMB to 3.6.8 as recommended.

 

Writing speed to array is ~30MB/sec which is OK (remember you are writing to protected array).

Reading speed has slightly increased to ~70-75MB/sec (well it probably depends on which disk is being read and what part of the disk - start/middle/end).

 

My server just finished it's monthly parity check.  Not happy with the speeds.  My config is in my signature.  The parity disk is plugged into one of the SATA_6 ports.

 

Last checked on Mon Oct 1 10:41:25 2012 SGT (today), finding 0 errors. 
* Duration: 9 hours, 41 minutes, 24 seconds. Average speed: 57.3 MB/sec

Mine took 6 hrs 25mins.  Very normal.  Also 2TB drives.

Seems to be working, only problem is the same as the last RC (and the test builds) and that's parity sync is a lot slower than earlier 5.0 builds and 4.7. Tunable (md_sync_window) is set to 512 as you suggested.

 

Parity build = 90MB/s to 110MB/s

Parity sync = 40MB/s to 65MB/s (this is way too slow, ~24 hour parity syncs every month, if anything sync should be faster than a build)

 

If I downgrade to B12a, I get much faster speeds but then I get SAS2LP errors. I'll keep using RC8 but I hope this is fixable.

 

Do you mean "Parity check" is slower?  (Parity sync to me is same thing as parity build.)  What's your h/w config?

 

Yes, Parity check is slow. If I invalidate my parity, it goes the correct speed (105MB/s roughly). It's only checking that's slow, which makes no sense to me. My monthly sync has peaked at 65MB/s, it's been going for 13 hours now and it's 53% done. Incredibly long. =/

 

3x SAS2LPs on a Supermicro MBD-X9SCM-F-O. I have 2 identical machines, both do it. The 3rd machine using SAT2-MV8 cards is faster, and it's using the much slower PCI-X 133mhz bandwidth. Downgrading to beta12a fixes this, so I refuse to blame my hardware. Main reason I don't list my hardware anymore is because I report it in every RC thread and just get tired of listing everything.

 

I hope this gets fixed. It seems like lots of people experience it, while others are totally unaffected.

 

My server just finished it's monthly parity check.  Not happy with the speeds.  My config is in my signature.  The parity disk is plugged into one of the SATA_6 ports.

 

Last checked on Mon Oct 1 10:41:25 2012 SGT (today), finding 0 errors. 
* Duration: 9 hours, 41 minutes, 24 seconds. Average speed: 57.3 MB/sec

 

Same speed as you roughly, but try having a 3TB parity with 3TB drives. My parity syncs take over a day on the latest RCs. I'd kill for 9 hour syncs, that's about what I should be getting with 3TB parity.

Seems to be working, only problem is the same as the last RC (and the test builds) and that's parity sync is a lot slower than earlier 5.0 builds and 4.7. Tunable (md_sync_window) is set to 512 as you suggested.

 

Parity build = 90MB/s to 110MB/s

Parity sync = 40MB/s to 65MB/s (this is way too slow, ~24 hour parity syncs every month, if anything sync should be faster than a build)

 

If I downgrade to B12a, I get much faster speeds but then I get SAS2LP errors. I'll keep using RC8 but I hope this is fixable.

 

Do you mean "Parity check" is slower?  (Parity sync to me is same thing as parity build.)  What's your h/w config?

 

Yes, Parity check is slow. If I invalidate my parity, it goes the correct speed (105MB/s roughly). It's only checking that's slow, which makes no sense to me. My monthly sync has peaked at 65MB/s, it's been going for 13 hours now and it's 53% done. Incredibly long. =/

 

3x SAS2LPs on a Supermicro MBD-X9SCM-F-O. I have 2 identical machines, both do it. The 3rd machine using SAT2-MV8 cards is faster, and it's using the much slower PCI-X 133mhz bandwidth.

 

My server just finished it's monthly parity check.  Not happy with the speeds.  My config is in my signature.  The parity disk is plugged into one of the SATA_6 ports.

 

Last checked on Mon Oct 1 10:41:25 2012 SGT (today), finding 0 errors. 
* Duration: 9 hours, 41 minutes, 24 seconds. Average speed: 57.3 MB/sec

 

Same speed as you roughly, but try having a 3TB parity with 3TB drives. My parity syncs take over a day on the latest RCs.

 

i noticed something very similar with what you're saying about "faster after invalidating parity".

 

when i added 2x 3.0TB drives to my array i did an initconfig, moved the old 2TBparity to disk2, put the new 3TB as parity and disk1 and started a new calc (both 3.0TB drives were pre-cleared).

 

I stopped the process mid-way somewhere to replace a cable as one drive was filling the syslog with comm errors. When i restarted the sync-calc it was 45mB/s! i let it run for a while and it never improved.

 

I stopped the sync, swapped disk1 and parity around and re-started the sync and it was 108mB/sec!

 

clearly something is not right here . . .

 

While I agree that it likely isn't your hardware's fault ...

Main reason I don't list my hardware anymore is because I report it in every RC thread and just get tired of listing everything.

 

That is what your sig is for, or even copy/paste from a nice little text file sitting in your docs.

Has anyone tried re-tuning the MD driver buffer setup to check for changes in parity check speed?

I had custom MD Driver buffer settings with 4.7, saw reference to one of Tom's post regarding those settings with 5RC and reverted to stock. (I kept the same custom MD settings though for my initial 5RC5 parity checks)

 

I've had slower parity checks since upgrading from 4.7 (to 5RC5?...and forward).

 

http://lime-technology.com/forum/index.php?topic=21269.msg189112#msg189112

 

And just got a SAS error on one of my SAS2LP. Tested the drive in question thoroughly, no SMART errors. I just can't win with unRAID anymore, headache after headache.

 

I will replace the drive and see if it happens again...

 

That is what your sig is for, or even copy/paste from a nice little text file sitting in your docs.

 

Funny thing about that, I use to have it in there, and people still asked my h/w config. After upgrading my server, just removed it completely.

syslog.txt