Prior to this past week, my system has been running without a hitch, no issues, etc.

This week, after only upgrading some plugins and binhex's sonarr, plex and couch (I'm assuming none of these are related to this issue, and I've gone thru their settings countless times, before and after having this issue start to occur) my system has now started to run mover at the correct time (3:00am) and what I can only guess, is again, at 8:15am....

 

Feb 28 03:19:16 MediaNAS kernel: mdcmd (44): spindown 0 (Routine)

Feb 28 03:33:15 MediaNAS kernel: mdcmd (45): spindown 1 (Routine)

Feb 28 03:34:16 MediaNAS kernel: mdcmd (46): spindown 2 (Routine)

Feb 28 08:30:46 MediaNAS kernel: mdcmd (47): spindown 0 (Routine)

Feb 28 08:45:45 MediaNAS kernel: mdcmd (48): spindown 1 (Routine)

Feb 28 08:45:47 MediaNAS kernel: mdcmd (49): spindown 2 (Routine)

 

So the 3am mover completes, nothing else occurs between those hours, nothing elses shows on log.  Then this past week, that 8:15am event occurs, and I can't for the life of me figure out what's causing this.  I have no cron.daily's.  Plex runs its maintenance at the same time as the 3am mover, so that's not the issue, and there's nowhere that I can think of in unraid settings that would have an additional cron time to run anything at 8am.

 

Has anyone else noticed this happen? Perhaps also this past week by some odd occurrence.

I'd like to run iotop or inotify but I'm not exactly sure how to go about outputting it to a log file or setting it up so that it works properly without getting endless cache_dirs folder scan spam.

 

Any help would be much appreciated if anyone can think of something new thats changed within these dockers (I only run plex, CP, Sonarr and nzbget, but those first 3 are the only ones that got updated recently) or unraid settings [6.1.8 - which also got the update recently] that defaults to that time in the morning. (8:15 specifically, since my parity spins down 15mins later, drives spin down 30min - so that matches those spin down times)

The syslog snippet you posted is not obvious evidence of mover as far as I can tell. Mover usually actually says mover in the syslog. Maybe post your complete diagnostics zip.

That's the thing though, there isn't anything else about this that makes it odd other than at 8:15am, parity and both drives spin up, which as far as I can tell from going through system settings for those dockers and unraid, to find this 8:15am cron that appears to not exist.

 

Feb 28 03:01:08 MediaNAS logger: mover started

Feb 28 03:01:08 MediaNAS logger: .d..t...... ./

Feb 28 03:01:08 MediaNAS logger: moving "Television"

Feb 28 03:01:08 MediaNAS logger: .d..t...... Television/

Feb 28 03:01:28 MediaNAS logger: .d..t...... Television/Treehouse.Masters/

Feb 28 03:01:28 MediaNAS logger: .d..t...... Television/Treehouse.Masters/Season.05/

Feb 28 03:01:28 MediaNAS logger: >f+++++++++ Television/Treehouse.Masters/Season.05/S05E06.-.Treehouse.Takeover.The.Roderick.Experience.HDTV-720p.x264.AC3.mkv

Feb 28 03:02:22 MediaNAS logger: ./Television/Treehouse.Masters/Season.05/S05E06.-.Treehouse.Takeover.The.Roderick.Experience.HDTV-720p.x264.AC3.nfo

Feb 28 03:02:22 MediaNAS logger: .d..t...... Television/Treehouse.Masters/Season.05/

Feb 28 03:02:22 MediaNAS logger: >f+++++++++ Television/Treehouse.Masters/Season.05/S05E06.-.Treehouse.Takeover.The.Roderick.Experience.HDTV-720p.x264.AC3.nfo

Feb 28 03:02:22 MediaNAS logger: skipping "appdata"

Feb 28 03:02:22 MediaNAS logger: mover finished

Feb 28 03:19:16 MediaNAS kernel: mdcmd (44): spindown 0 (Routine)

Feb 28 03:33:15 MediaNAS kernel: mdcmd (45): spindown 1 (Routine)

Feb 28 03:34:16 MediaNAS kernel: mdcmd (46): spindown 2 (Routine)

Feb 28 08:30:46 MediaNAS kernel: mdcmd (47): spindown 0 (Routine)

Feb 28 08:45:45 MediaNAS kernel: mdcmd (48): spindown 1 (Routine)

Feb 28 08:45:47 MediaNAS kernel: mdcmd (49): spindown 2 (Routine)

 

Nothing else occurs between those times

If the mover ran again you would see it in the log even it it didn't move anything, e.g,:

 

Feb 27 03:40:01 Tower5 logger: mover started
Feb 27 03:40:01 Tower5 logger: skipping "appdata"
Feb 27 03:40:01 Tower5 logger: skipping "dropbox"
Feb 27 03:40:01 Tower5 logger: skipping "jdownloader"
Feb 27 03:40:01 Tower5 logger: skipping "pyload"
Feb 27 03:40:01 Tower5 logger: skipping "torrents"
Feb 27 03:40:01 Tower5 logger: skipping "usenet"
Feb 27 03:40:01 Tower5 logger: mover finished
Feb 28 03:40:01 Tower5 logger: mover started
Feb 28 03:40:01 Tower5 logger: skipping "appdata"
Feb 28 03:40:01 Tower5 logger: skipping "dropbox"
Feb 28 03:40:01 Tower5 logger: skipping "jdownloader"
Feb 28 03:40:01 Tower5 logger: skipping "pyload"
Feb 28 03:40:01 Tower5 logger: skipping "torrents"
Feb 28 03:40:01 Tower5 logger: skipping "usenet"
Feb 28 03:40:01 Tower5 logger: mover finished

You need to look at all your client systems and plugins and docker containers see what they're doing at 8:15.

That's what I thought, and I have no issues with a drive spinning if it's in use... but no one else uses this server but me, and I was asleep at the time any time these spin ups are happening.

 

Yeah I guess I'll have to take a closer look at docker logs, I just don't know what caused this all of a sudden.

If you can, shutdown all your dockers for 1 morning, see if it happens.

Then enable 1 docker per following morning and see how it behaves.

 

It might be some scanning behavior the application in the docker does.

 

Also,  are you running cachedirs? That might help with keeping drives spun down if apps are only checking dirs and filenames.

If you can, shutdown all your dockers for 1 morning, see if it happens.

Then enable 1 docker per following morning and see how it behaves.

 

It might be some scanning behavior the application in the docker does.

 

Also,  are you running cachedirs? That might help with keeping drives spun down if apps are only checking dirs and filenames.

 

Yep that was my next course of action with the dockers, and yes I use cachedirs.

Something I recently updated must have changed and created this.

Figured out the issue causing this "full drive spin" issue.

Sonarr, it's full update library is for some reason completely spinning even though everything should all be in cache.

 

At 8:15pm and 8:15am, it's doing it.

The only culprit I can think of that would be causing this is I recently started using the metadata function for it, and something tells me it's double checking everything against what it has on file.

 

 

It is writing anything it gets/new to the cache first, but I'm assuming it has to double check against whats on the array first - thus spinning.

Is this normal for those with metadata enabled? Kodi specifically.