rsbuc

Sure! see attached This log has my array going from normal temps to 57c which is above my CRIT level. syslog.txt

Hello! I was having an issue before where my Incremental parity checks were not reading the disk temperatures correctly when the disks had spun down (they were reporting "=*". I have updated to the latest version of the Parity Tuning Script, and now the script doesn't appear to be collecting/detecting the disk temperature at all anymore. here is a snippet from the syslog (with Testing logs enabled) *** Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR ----------- MONITOR begin ------ Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR /boot/config/forcesync marker file present Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR manual marker file present Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR parityTuningActive=1, parityTuningPos=886346616 Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR appears there is a running array operation but no Progress file yet created Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR ... appears to be manual parity check Mar 11 13:30:22 219STORE Parity Check Tuning: DEBUG: Manual Correcting Parity-Check Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR MANUAL record to be written Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR Current disks information saved to disks marker file Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR written header record to progress marker file Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR ... appears to be manual parity check Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR written MANUAL record to progress marker file Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR Creating required cron entries Mar 11 13:30:22 219STORE Parity Check Tuning: DEBUG: Created cron entry for scheduled pause and resume Mar 11 13:30:22 219STORE Parity Check Tuning: DEBUG: Created cron entry for 6 minute interval monitoring Mar 11 13:30:22 219STORE Parity Check Tuning: DEBUG: updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR CA Backup not running, array operation paused Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR ... no action required Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR global temperature limits: Warning: 50, Critical: 55 Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR plugin temperature settings: Pause 3, Resume 8 Mar 11 13:30:22 219STORE Parity Check Tuning: DEBUG: array drives=0, hot=0, warm=0, cool=0, spundown=0, idle=0 Mar 11 13:30:22 219STORE Parity Check Tuning: DEBUG: Array operation paused but not for temperature related reason Mar 11 13:30:22 219STORE Parity Check Tuning: TESTING:MONITOR ----------- MONITOR end ------ *** the parity check tuning clearly shows "Warm=0, Cool=0, Spundown=0" but there are several disks above 55c. and heres a screenshot of the disk temps in the webui. (thanks again for reading this message)

No worries, I appreciate the effort, if you'd like more info let me know.

I've finally had a few mins to test this out with the TESTING log mode enabled. I think you were hinting at what I've seen. When the array goes into 'overheat mode' and the parity check pauses, the disks eventually spin down and the temperature value in the log goes to "Temp=*" instead of showing an actual Temperature value, so the Parity Check Tuning script doesn't see a valid numerical temperature value to resume the parity check process. after waiting ~12minutes, I manually clicked 'spin up disks' and then 6minutes later the parity check process resumed as it was able to see the temperature values when the disks were spun up. I'm attaching my syslog. syslog.txt

Interesting, I've enabled Debug logging, and that totally demystifies a lot of what the plugin is doing (Thanks for that). Here is what I'm seeing (I'm sure I have a bad setting or something) -- I start the parity check, it runs for an hour or so, then the hard drives hit their temperature limit, and the parity check pauses. The drives spin down, and the drives cool off, but the plugin doesn't seem to resume the parity operations. If I "Spin up all disks" it will detect the drive temperatures as being cool again and resume the parity check. are there special disk settings that I need to enable for this to work properly? (also, thanks again for trying to helping me out!)

Hello! Am I understanding this correctly? The plugin will pause the parity operation when the disks reach the temperature threshold and wait until the temps fall below the temperature threshold value -- then the script immediately resume the parity operations? or will it only attempt to resume after the 'Increment resume time' schedule?

Hey Everyone! I've been trying to get the "Increment Frequency/Custom" working for what I need, but I'm struggling. I have cooling issues with my Unraid, and what my goal is to allow the the Parity Check to 'Pause when disks overheat', then have the Custom Increment frequency pause the Parity operations for ~30mins to let the disks cool down, and then resume (or at least check if the disks are cooled down enough) and then Resume parity operations. Clearly my cron skills are weak, is there an "Increment Resume Time" and "Increment Pause Time" that someone can suggest? (thanks again for all the awesome features in the Parity Check Tuning plugin!)

Thanks for the advice, i upgraded to the latest version, and i've been able to swap out 3 disks so far with larger disks, and i received no errors on rebuild. Maybe it was a funny driver version for my sas cards in that specific version of unraid. Thanks again!

Write errors during array expansion/rebuild Hey guys, first let me say that I've been an unraid user for several years, and I've had to visit the forum on numerous occasions, and have usually found solutions/similar problems to my issues (thank you all). But this time i haven't found an identical issue. I am running Unraid 6.0-rc3, in my Norco 24bay chassis (with some off the shelf Intel/asus cpu/motherboard) Here is what has happened so far. I decided to swap out disk17 in my unraid to upgrade its size, i was going from a 6tb to an 8tb drive. The 8tb drive i had pre-cleared ~6times or so without any issues. I stopped the array as i normally would, i removed disk17, waited ~30secs, installed the new 8tb disk into the disk17 position, waited ~30secs for the drive to be detected. Selected the new 8tb disk in the unraid UI (in the disk17 position), and selected 'Rebuild/Expand' and started the array. The array began rebuilding, and the following morning (Today) the rebuild had completed, but instead of all of the disks having a 'green ball' next to it, Disk17 had a 'gray triangle'. Checking the syslog, i found a bunch of 'Write Errors'. I stopped the array, reseated disk17 in the array, and rebooted unraid. Unraid started, but disk17 still has a 'gray triangle' on it - and in my dashboard view, i have a 'Data is Invalid' warning at the bottom. What should i try next? Attached is my syslog and a couple screenshots syslog.zip

That is correct, my initial plan was to replace an existing 4tb disk with a 6tb disk, but numerous write errors caused the expansion/rebuild to fail. When i reseated the 6tb disk, i tried to restart the array with the same 6tb disk that had write errors, the array started with that drive showing "unformatted" and it started to rebuild the parity disk for the array with disk19 "missing" (since it was showing unformatted). I didnt catch it until it already started to rebuild parity. So i stopped the array, replaced disk 19, with a fresh 6tb disk, formatted it, and started the array (parity) rebuild.

Hey guys, just figured i'd update my issue, incase anyone has it in the future. I stopped the array, reseated the drive, and started the array again. Unraid detected the drive, but it detected it as "Unformatted". So it rebuilt parity for the array, with a missing/blank Disk19. I stopped the array rebuild, replaced disk19 with a new disk, formatted disk19, and rebuilt the array again (which regenerated the parity with a blank disk19). Everything appears to be fine, but i will have to copy the data from the old disk19 to the new disk19. Thanks again for all the help! rsbuc

I'll stop the array tomorrow, and reseat the drive (its plugs into a backplane on the norco), and the other drives on that backplane appear to be fine.

Sadly no, i didn't run a pre-clear on it (i think i learned a valuable lesson about skipping the preclear). i can't seem to run a SMART test on it, when i 'spin up all drives' every drive except disk19 goes 'green ball', but disk19 stays as a gray triangle. When i try to run a SMART test on it, it says that it needs to be spun up (but disk19 will not spin up).

Hey guys, i've been running unraid for quite sometime, and i couldn't be happier, its been great. My system info is. Unraid V6.0-rc3 24bay norco chassis, 21disks I tried to replace one of my existing 4tb drives (disk19) with a 6tb drive (which I've done numerous times before), but this time, when i restarted the array to start up the array expansion, it started the rebuild, but when i checked on it a couple hours later, the rebuild stopped, and the newly replaced disk has a gray triangle on it, and my 'Parity status' is 'Data is invalid'. The array is started, and its serving data fine. When i check the logs i see... **** Dec 17 11:22:38 UNRAID kernel: sd 9:0:9:0: [sdw] tag#4 CDB: opcode=0x8a 8a 00 00 00 00 00 f0 ee 7a 08 00 00 04 00 00 00 Dec 17 11:22:38 UNRAID kernel: blk_update_request: I/O error, dev sdw, sector 4042160648 Dec 17 11:22:38 UNRAID kernel: sd 9:0:9:0: [sdw] tag#5 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Dec 17 11:22:38 UNRAID kernel: sd 9:0:9:0: [sdw] tag#5 CDB: opcode=0x8a 8a 00 00 00 00 00 f0 ee 76 08 00 00 04 00 00 00 Dec 17 11:22:38 UNRAID kernel: blk_update_request: I/O error, dev sdw, sector 4042159624 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164680 Dec 17 11:22:38 UNRAID kernel: md: md_do_sync: got signal, exit... Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164688 Dec 17 11:22:38 UNRAID kernel: sd 9:0:9:0: [sdw] tag#6 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164696 Dec 17 11:22:38 UNRAID kernel: sd 9:0:9:0: [sdw] tag#6 CDB: opcode=0x8a 8a 00 00 00 00 00 f0 ee 72 08 00 00 04 00 00 00 Dec 17 11:22:38 UNRAID kernel: blk_update_request: I/O error, dev sdw, sector 4042158600 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164704 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164712 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164720 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164728 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164736 Dec 17 11:22:38 UNRAID kernel: sd 9:0:9:0: [sdw] tag#7 UNKNOWN(0x2003) Result: hostbyte=0x04 driverbyte=0x00 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164744 Dec 17 11:22:38 UNRAID kernel: sd 9:0:9:0: [sdw] tag#7 CDB: opcode=0x8a 8a 00 00 00 00 00 f0 ee aa 08 00 00 04 00 00 00 Dec 17 11:22:38 UNRAID kernel: blk_update_request: I/O error, dev sdw, sector 4042172936 Dec 17 11:22:38 UNRAID kernel: md: disk19 write error, sector=4042164752 **** and the "disk19 write error, sector=....." continues for numerous pages. it looks like Disk19 went bad during the expansion, what is my suggested next step here? Am i safe to stop the array, remove 'disk19' and replace it with another 6tb drive? Will it rebuild correctly? Any help would be appreciated!

Hey BDHarrington, in my attempt to troubleshoot my issue i ended up disabling all of my plugins, but i still had strange/random lockups about once a week (followed by a lengthy consistency check). I considered dropping my system memory down to 4gb (From 16gb) and doing a fresh install without any plugins, but just as i was about to remove the dimm's version 6.0b3 got its release, so instead i installed 6.0b3 and its been working great, Previously my uptime wouldn't be longer than a week without a strange lockup; now its 64days of uptime. on a side now, i have since moved my plex service to a vm on my hyper-v host. I couldn't be happier with v6.0b3!