mr-hexen Posted September 26, 2012 Share Posted September 26, 2012 did you let it finish completely? Quote Link to comment
pras1011 Posted September 26, 2012 Share Posted September 26, 2012 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. Quote Link to comment
jumperalex Posted September 26, 2012 Share Posted September 26, 2012 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. Quote Link to comment
pras1011 Posted September 26, 2012 Share Posted September 26, 2012 It's currently at 12% and its still at 42MB/s. Quote Link to comment
PeterB Posted September 27, 2012 Share Posted September 27, 2012 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. Quote Link to comment
optiman Posted September 27, 2012 Share Posted September 27, 2012 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. Quote Link to comment
Influencer Posted September 27, 2012 Share Posted September 27, 2012 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. Quote Link to comment
JackBauer Posted September 27, 2012 Share Posted September 27, 2012 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. Quote Link to comment
optiman Posted September 27, 2012 Share Posted September 27, 2012 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. Quote Link to comment
pras1011 Posted September 27, 2012 Share Posted September 27, 2012 You can uncheck it. Just uncheck it and then click start parity and the goto syslog and it will say NOCORRECT. Quote Link to comment
optiman Posted September 27, 2012 Share Posted September 27, 2012 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. Quote Link to comment
Joe L. Posted September 27, 2012 Share Posted September 27, 2012 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) Quote Link to comment
optiman Posted September 27, 2012 Share Posted September 27, 2012 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. Quote Link to comment
peter_sm Posted September 29, 2012 Share Posted September 29, 2012 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 Quote Link to comment
generalz Posted September 29, 2012 Share Posted September 29, 2012 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.. Quote Link to comment
PeteAron Posted September 29, 2012 Share Posted September 29, 2012 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. Quote Link to comment
theone Posted September 29, 2012 Share Posted September 29, 2012 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). Quote Link to comment
dalben Posted October 1, 2012 Share Posted October 1, 2012 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 Quote Link to comment
S80_UK Posted October 1, 2012 Share Posted October 1, 2012 Mine took 6 hrs 25mins. Very normal. Also 2TB drives. Quote Link to comment
tyrindor Posted October 1, 2012 Share Posted October 1, 2012 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. Quote Link to comment
mr-hexen Posted October 1, 2012 Share Posted October 1, 2012 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 . . . Quote Link to comment
jumperalex Posted October 1, 2012 Share Posted October 1, 2012 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. Quote Link to comment
WeeboTech Posted October 1, 2012 Share Posted October 1, 2012 Has anyone tried re-tuning the MD driver buffer setup to check for changes in parity check speed? Quote Link to comment
mbryanr Posted October 1, 2012 Share Posted October 1, 2012 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 Quote Link to comment
tyrindor Posted October 2, 2012 Share Posted October 2, 2012 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 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.