estrim

Apologies, that's my fault for not reading properly! My answer to this seems to be no&yes - whilst there are of course many cases, in my particular case where I know a parity operation already kicked off, having notifications that my mover caused it to stop/start every hour when the mover is chugging along is not useful. Hope that's at least one perspective! Thanks again

Running 2023.09.06 (and the others this month) I am getting notifications when my config does not have such options enabled (afaik!) - config: # cat /boot/config/plugins/parity.check.tuning/parity.check.tuning.cfg parityTuningScheduled="0" parityTuningManual="0" parityTuningAutomatic="0" parityTuningFrequency="0" parityTuningResumeCustom="5,15,25,35,45,55 * * * *" parityTuningResumeDay="0" parityTuningResumeHour="0" parityTuningResumeMinute="15" parityTuningPauseCustom="0,10,20,30,40,50 * * * *" parityTuningPauseDay="0" parityTuningPauseHour="0" parityTuningPauseMinute="10" parityTuningNotify="0" parityTuningRecon="0" parityTuningClear="0" parityTuningRestart="1" parityTuningMover="1" parityTuningCABackup="1" parityTuningHeat="0" parityTuningHeatHigh="3" parityTuningHeatLow="8" parityTuningHeatNotify="1" parityTuningHeatShutdown="0" parityTuningHeatCritical="2" parityTuningHeatTooLong="30" parityTuningLogging="0" parityTuningLogTarget="0" parityTuningMonitorDefault="17" parityTuningMonitorHeat="7" parityTuningMonitorBusy="6" parityTuningMonitorPartial="1" parityProblemType="sector" parityProblemStartSector="0" parityProblemStartPercent="0" parityProblemEndSector="100" parityProblemEndPercent="0" parityProblemCorrect="0" parityTuningBackup="1" parityTuningShutdown="0" GUI: Yet I'm getting 'mover no longer running' and 'mover running' notifications. Any ideas? Thanks! E

Thanks for this! - Resolved my issues

Sure thing - changed the logging, rebooted - You'll see the plugin start at 13:17:22, I clicked 'resume' at 13:17:43, at 14:28:25 you will see the 'outside increment window' message, at 14:44:07 the mover finishes running and mentions the same 'outside increment window' message. Thanks

Thanks for the quick update! I did the update as per the screenshot I'm running 2023.08.23 I also see the file: # md5sum /boot/config/plugins/parity.check.tuning/parity.check.tuning-2023.08.23.txz be35b73c7c37eee02f3da99688833180 /boot/config/plugins/parity.check.tuning/parity.check.tuning-2023.08.23.txz However my logs say: Aug 23 16:27:40 unraid01 Parity Check Tuning: Versions: Unraid 6.12.3, Plugin Version: 2023.07.21 Aug 23 16:27:40 unraid01 Parity Check Tuning: Configuration: Array#012(#012 [parityTuningScheduled] => 0#012 [parityTuningManual] => 0#012 [parityTuningAutomatic] => 0#012 [parityTuningFrequency] => 0#012 [parityTuningResumeCustom] => 5,15,25,35,45,55 * * * *#012 [parityTuningResumeDay] => 0#012 [parityTuningResumeHour] => 0#012 [parityTuningResumeMinute] => 15#012 [parityTuningPauseCustom] => 0,10,20,30,40,50 * * * *#012 [parityTuningPauseDay] => 0#012 [parityTuningPauseHour] => 0#012 [parityTuningPauseMinute] => 10#012 [parityTuningNotify] => 0#012 [parityTuningRecon] => 0#012 [parityTuningClear] => 0#012 [parityTuningRestart] => 1#012 [parityTuningShutdown] => 0#012 [parityTuningMover] => 1#012 [parityTuningBackup] => 1#012 [parityTuningHeat] => 0#012 [parityTuningHeatHigh] => 3#012 [parityTuningHeatLow] => 8#012 [parityTuningHeatNotify] => 1#012 [parityTuningHeatShutdown] => 0#012 [parityTuningHeatCritical] => 2#012 [parityTuningHeatTooLong] => 30#012 [parityTuningLogging] => 1#012 [parityTuningLogTarget] => 0#012 [parityTuningMonitorDefault] => 17#012 Aug 23 16:27:40 unraid01 Parity Check Tuning: DEBUG: Created cron entry for 6 minute interval monitoring Aug 23 16:27:40 unraid01 Parity Check Tuning: DEBUG: Updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron I continued assuming the version text was possibly not updated and unfortunately the 'outside increment window' message still appears. # grep -E 'Parity|md:|move' /var/log/syslog Aug 23 23:00:02 unraid01 root: mover: started ... Aug 23 23:00:29 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 23 23:00:29 unraid01 Parity Check Tuning: Send notification: mover running: Aug 23 23:00:30 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 23 23:00:30 unraid01 Parity Check Tuning: DEBUG: detected that mdcmd had been called from sh with command mdcmd nocheck PAUSE Aug 23 23:00:35 unraid01 Parity Check Tuning: DEBUG: ...Pause Automatic Correcting Parity-Check Aug 23 23:00:35 unraid01 Parity Check Tuning: DEBUG: Created cron entry for 6 minute interval monitoring Aug 23 23:00:35 unraid01 Parity Check Tuning: DEBUG: Updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron Aug 23 23:00:35 unraid01 kernel: md: recovery thread: exit status: -4 Aug 23 23:00:35 unraid01 Parity Check Tuning: Paused: Automatic Correcting Parity-Check (13.6% completed) Aug 23 23:00:57 unraid01 root: mover: finished Aug 23 23:07:07 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused Aug 23 23:07:07 unraid01 Parity Check Tuning: Send notification: mover no longer running: Aug 23 23:07:08 unraid01 Parity Check Tuning: Array operation not resumed - outside increment window: Automatic Correcting Parity-Check (13.6% completed) Aug 23 23:12:40 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused Aug 23 23:18:30 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused Thanks!

Run into something odd myself that is kind of like the above - I have no increment windows set, my parity is checking due to a unclean shutdown and I see this: # grep -E 'Parity|md:' /var/log/syslog ... Aug 23 00:48:38 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 23 00:54:23 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 23 01:00:32 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 23 01:00:32 unraid01 Parity Check Tuning: Send notification: mover running: Aug 23 01:00:33 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 23 01:00:33 unraid01 Parity Check Tuning: DEBUG: detected that mdcmd had been called from sh with command m dcmd nocheck PAUSE Aug 23 01:00:38 unraid01 Parity Check Tuning: DEBUG: ...Pause Automatic Correcting Parity-Check Aug 23 01:00:38 unraid01 Parity Check Tuning: DEBUG: Created cron entry for 6 minute interval monitoring Aug 23 01:00:38 unraid01 Parity Check Tuning: DEBUG: Updated cron settings are in /boot/config/plugins/parity.c heck.tuning/parity.check.tuning.cron Aug 23 01:00:38 unraid01 kernel: md: recovery thread: exit status: -4 Aug 23 01:00:38 unraid01 Parity Check Tuning: Paused: Automatic Correcting Parity-Check (2.8% completed) Aug 23 01:06:35 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused Aug 23 01:06:35 unraid01 Parity Check Tuning: Send notification: mover no longer running: Aug 23 01:06:36 unraid01 Parity Check Tuning: Array operation not resumed - outside increment window: Automatic Correcting Parity-Check (2.8% completed) Aug 23 01:12:37 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused Aug 23 01:18:29 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused Aug 23 01:24:35 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused Aug 23 01:30:33 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check paused ... Config - # cat /boot/config/plugins/parity.check.tuning/parity.check.tuning.cfg parityTuningScheduled="0" parityTuningManual="0" parityTuningAutomatic="0" parityTuningFrequency="0" parityTuningResumeCustom="5,15,25,35,45,55 * * * *" parityTuningResumeDay="0" parityTuningResumeHour="0" parityTuningResumeMinute="15" parityTuningPauseCustom="0,10,20,30,40,50 * * * *" parityTuningPauseDay="0" parityTuningPauseHour="0" parityTuningPauseMinute="10" parityTuningNotify="0" parityTuningRecon="0" parityTuningClear="0" parityTuningRestart="1" parityTuningMover="1" parityTuningCABackup="1" parityTuningHeat="0" parityTuningHeatHigh="3" parityTuningHeatLow="8" parityTuningHeatNotify="1" parityTuningHeatShutdown="0" parityTuningHeatCritical="2" parityTuningHeatTooLong="30" parityTuningLogging="1" parityTuningLogTarget="0" parityTuningMonitorDefault="17" parityTuningMonitorHeat="7" parityTuningMonitorBusy="6" parityTuningMonitorPartial="1" parityProblemType="sector" parityProblemStartSector="0" parityProblemStartPercent="0" parityProblemEndSector="100" parityProblemEndPercent="0" parityProblemCorrect="0" parityTuningBackup="1" parityTuningShutdown="0" I am therefore wondering why I'm getting "Aug 23 01:06:36 unraid01 Parity Check Tuning: Array operation not resumed - outside increment window: Automatic Correcting Parity-Check". Tell me I'm doing something silly please

Thanks for having a look and fishing that out! Looks like looking for /usr/local/sbin/mover is probably a better move (but a pain if they ever move the binary). Since in my case it is a log file which is always open and in the process table - yeah, however I simply changed the name to work around it for the time being. Many thanks!

QQ - It appears as soon as I have a process that contains the words 'mover' my parity-check pauses (as per my settings) - anyone seen that? E.g: Aug 22 00:24:24 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 22 00:24:24 unraid01 Parity Check Tuning: Send notification: mover running: Aug 22 00:24:24 unraid01 Parity Check Tuning: DEBUG: Automatic Correcting Parity-Check running Aug 22 00:24:24 unraid01 Parity Check Tuning: DEBUG: detected that mdcmd had been called from sh with command mdcmd nocheck PAUSE Aug 22 00:24:29 unraid01 Parity Check Tuning: DEBUG: ...Pause Automatic Correcting Parity-Check Aug 22 00:24:29 unraid01 Parity Check Tuning: DEBUG: Created cron entry for scheduled pause and resume Aug 22 00:24:29 unraid01 Parity Check Tuning: DEBUG: Created cron entry for 6 minute interval monitoring Aug 22 00:24:30 unraid01 Parity Check Tuning: DEBUG: Updated cron settings are in /boot/config/plugins/parity.check.tuning/parity.check.tuning.cron Aug 22 00:24:30 unraid01 kernel: mdcmd (48): nocheck PAUSE Aug 22 00:24:30 unraid01 kernel: Aug 22 00:24:30 unraid01 kernel: md: recovery thread: exit status: -4 Aug 22 00:24:30 unraid01 Parity Check Tuning: Paused: Automatic Correcting Parity-Check (1.9% completed) When: root@unraid01:/mnt/user/my_repo# ps -ef | grep move root 11163 10958 0 00:22 ? 00:00:00 tee -a /mnt/user/appdata/mystuff/log/unraid01-doingmoverXfer.log I tried to figure out in the php how it 'greps' for the mover running but not very comfortable with it. Thanks

Hi, My USB stick is about to run out of space - it appears in early January I had a commit per minute'ish (which has since stopped) which presumably have not helped: root@unraid01:/boot# du -h .git | tail -1 13G .git My commits: root@unraid01:/boot# git log | grep ^Date | wc -l 136591 As can be seen this last commited a while ago: root@unraid01:/boot# git log | grep ^Date | head -10 Date: Sat Jan 1 23:58:04 2022 +0000 Date: Sat Jan 1 23:57:04 2022 +0000 Date: Sat Jan 1 23:56:03 2022 +0000 Date: Sat Jan 1 23:55:04 2022 +0000 Date: Sat Jan 1 23:54:04 2022 +0000 Date: Sat Jan 1 23:53:04 2022 +0000 Date: Sat Jan 1 23:51:04 2022 +0000 Date: Sat Jan 1 23:48:03 2022 +0000 Date: Sat Jan 1 23:47:03 2022 +0000 Date: Sat Jan 1 23:45:04 2022 +0000 Is there a recommended / safe way to purge some of the older history? Thanks!

Oh no - I know it is not much help but I've just upgraded to 6.9 and use a LSI 9206-16e card and it all just worked and appeared as before. I think you can downgrade to verify (not done it myself though).

The DS has no concept of 'shutdown' it is either on or off. Therefore I keep my DS on a seperate UPS - so that the Unraid server and its mounts get shut down cleanly before the DS runs out of juice.

I seem to recall that SMART data was fine.

FWIW - This worked for me with the onboard on a DL380 G8 to get it in HBA mode. The drive temperatures would just disappear after a few days though - so moved to a H220 since

Did you get anywhere with this? I got a PM8003 as well and it is just not being detected on Unraid on a HP DL380 G8. It has worked with a Netapp X2065A-R6 card - but the PCIe is full-length so does not really fit in my case

Hi, I'm a Unraid noob but have been using NFS for 20 odd years, my use case is a couple of Raspberry PI's utilising NFS root filesystems (ie. network boot) which I'm moving from some QNAP's over to Unraid. Whilst booting over NFS is working as expected, I am having a hard time keeping these up for more than a couple of hours, as I/O type errors get logged on the RPI's. I am therefore keen to hear if anyone else is using nfs root successfully, and if so what export and root mount options worked for you. With some playing & reading I've, Disabled hardlinking to avoid the stale NFS handle issues Disabled my cache drive on the share to avoid what I can from a inode-move-perspective Export settings wise I've played with combinations of sec=sys,rw,no_root_squash,insecure,no_subtree_check,async & sync On the RPI side I've played with: udp,vers=3,lock, nolock, wsize&rsize's Appreciate any pointers!