Installed my two unraid reiserfs datadrives to old Linux box and copied all the stuff to the new drivers. After puting the drives back to unraid box and started parity check in, estimated speed is under 500kb/s and estimated finish is changing between 100-300 days! Sync errors corrected is growing, now it sits around 600000.

 

When i was setting up the system the speed of the parity check was good, around 150mb/s according to web ui.

 

Unraid is running on a h55 mb + core i3, 4 gigs of memory and 4tb and 2tb drives connected to LSI SAS 9211-8i SAS-controller (initiator target mode). Unraid v6 b3.

 

Is this normal (propably not??), and is there any way to speed things up?

 

Mar 24 11:45:16 Tower kernel: mdcmd (35): check CORRECT
Mar 24 11:45:16 Tower kernel: md: recovery thread woken up ...
Mar 24 11:45:16 Tower kernel: md: recovery thread checking parity...
Mar 24 11:45:16 Tower kernel: md: using 1536k window, over a total of 3907018532 blocks.
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22072
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22080
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22088
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22096
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22104
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22112
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22120
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22128
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22136
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22144
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22152
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22160
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22168
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22176
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22184
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22192
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22200
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22208
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22216
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22224
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22232
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22240
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22248
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22256
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22264
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22272
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22280
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22288
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22296
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22304
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22312
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22320
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22328
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22336
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22344
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22352
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22360
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22368
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22376
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22384
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22392
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22400
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22408
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22416
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22424
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22432
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22440
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22448
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22456
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22464
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22472
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22480
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22488
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22496
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22504
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22512
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22520
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22528
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22536
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22544
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22552
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22560
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22568
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22576
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22584
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22592
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22600
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22608
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22616
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22624
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22632
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22640
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22648
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22656
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22664
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22672
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22680
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22688
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22696
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22704
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22712
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22720
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22728
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22736
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22744
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22752
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22760
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22768
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22776
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22784
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22792
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22800
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22808
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22816
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22824
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22832
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22840
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22848
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22856
Mar 24 11:45:17 Tower kernel: md: correcting parity, sector=22864
Mar 24 11:45:17 Tower kernel: md: correcting parity, stopped logging

You put 2 drives with new data there at a same time and ran parity check?

You have left out a lot of details. Let me see if I can fill in the blanks.

 

You had some drives in an unRAID array with parity.

 

You removed them, put them into another system, and wrote to them.

 

You put them back in your unRAID array and started it.

 

Then you started a parity check. You really should have done a New Configuration at this point and started a parity build since you made your parity invalid by writing to the disks in another system.

 

Now it is trying to correct parity instead of rebuilding it. I am not sure if this would be a lot slower than just rebuilding it or not. I can imagine that it would be since it would first try to read parity and all of the other disks before writing parity, instead of just reading all of the other disks and writing parity.

 

Is this what happened? If so you might as well just stop the parity check, do a New Configuration, and let it rebuild parity like you should have done. If you are unsure how to do this ask. The main thing is make sure you know which disk belongs where, especially your parity drive.

It sounds like you did exactly what trurl outlined above.    If so, do what he suggested:  Stop the parity check;  Stop the array;  Go to the Utils tab and click on "New Config" and reset your configuration [be CERTAIN you assign the drives correctly ... if you assign the wrong drive to parity you'll wipe out all data on that drive];  and then Start the array and let it do the initial parity sync.    After the parity sync completes (a few hours), do a Parity Check to confirm all is okay.

 

Note that once your array is parity protected, you should NOT do any writes to those drives "outside" of UnRAID 

Thank you very much Trurl and Garycase! I deleted the old config, rebuild it and now the parity-sync is running around ~150mb/sec so everything seems to be allright.

 

So i guess it is a bad idea to write to reiserfs partitions outside the unraid machine? I had around 4TB of data that needed to be transferred to unraid box, and i read somewhere (a thread in this forum if i am not mistaken) that you can just mount the unraid hdd's in another box and transfer the files. Would have done it the other way around (old hdd's to new unraid box) , but the old drivers were formatted in xfs and that is not supported in unraid...

Probably what was recommended was doing that before adding a parity drive. Once you have parity it must be involved in all writes to the array drives or it will not be in sync. A write to a data drive in an unRAID with parity always writes parity too so it is always in sync.