Not sure if I should put this here but when my mover script runs all my disks spin up and all my disk will only spin down after the moved script has finished so even only when 1 disk is being written to and should the other should spin down after 1 hour they are only spinning down 1 hour after the mover.  Here is what has happened the last 2 nights

 

Sep 4 03:40:01 Tower logger: mover started

Sep 4 03:40:01 Tower logger: skipping Apps/

Sep 4 03:40:01 Tower logger: moving Movies/

Sep 4 03:40:01 Tower logger: ./Movies/ACE_PENTURA.ISO

Sep 4 03:40:01 Tower logger: >f+++++++++ Movies/ACE_PENTURA.ISO

Sep 4 03:52:04 Tower logger: ./Movies/THE_LITTLE_DERMAID.ISO

Sep 4 03:52:04 Tower logger: >f+++++++++ Movies/THE_LITTLE_DERMAID.ISO

Sep 4 04:12:32 Tower logger: ./Movies/

Sep 4 04:12:32 Tower logger: mover finished

Sep 4 05:13:00 Tower kernel: mdcmd (164): spindown 0 (Routine)

Sep 4 05:14:31 Tower kernel: mdcmd (165): spindown 2 (Routine)

Sep 4 05:14:42 Tower kernel: mdcmd (166): spindown 1 (Routine)

Sep 4 05:14:42 Tower kernel: mdcmd (167): spindown 3 (Routine)

Sep 4 05:14:43 Tower kernel: mdcmd (168): spindown 4 (Routine)

Sep 4 05:14:44 Tower kernel: mdcmd (169): spindown 5 (Routine)

Sep 4 05:14:44 Tower kernel: mdcmd (170): spindown 6 (Routine)

Sep 4 05:14:45 Tower kernel: mdcmd (171): spindown 7 (Routine)

Sep 4 05:14:46 Tower kernel: mdcmd (172): spindown 8 (Routine)

Sep 4 05:14:47 Tower kernel: mdcmd (173): spindown 9 (Routine)

Sep 4 05:14:47 Tower kernel: mdcmd (174): spindown 10 (Routine)

Sep 4 05:14:48 Tower kernel: mdcmd (175): spindown 11 (Routine)

Sep 4 15:39:29 Tower kernel: mdcmd (176): spindown 1 (Routine)

Sep 5 03:40:01 Tower logger: mover started

Sep 5 03:40:01 Tower logger: skipping Apps/

Sep 5 03:40:01 Tower logger: moving Movies/

Sep 5 03:40:01 Tower logger: ./Movies/WORLD_WAR_C_UNRATED.ISO

Sep 5 03:40:01 Tower logger: >f+++++++++ Movies/WORLD_WAR_C_UNRATED.ISO

Sep 5 04:03:00 Tower logger: ./Movies/WORLD_WAR_C.ISO

Sep 5 04:03:00 Tower logger: >f+++++++++ Movies/WORLD_WAR_C.ISO

Sep 5 04:30:43 Tower logger: ./Movies/

Sep 5 04:30:43 Tower logger: mover finished

Sep 5 05:31:13 Tower kernel: mdcmd (177): spindown 0 (Routine)

Sep 5 05:32:33 Tower kernel: mdcmd (178): spindown 2 (Routine)

Sep 5 05:32:44 Tower kernel: mdcmd (179): spindown 1 (Routine)

Sep 5 05:32:44 Tower kernel: mdcmd (180): spindown 3 (Routine)

Sep 5 05:32:45 Tower kernel: mdcmd (181): spindown 4 (Routine)

Sep 5 05:32:46 Tower kernel: mdcmd (182): spindown 5 (Routine)

Sep 5 05:32:46 Tower kernel: mdcmd (183): spindown 6 (Routine)

Sep 5 05:32:47 Tower kernel: mdcmd (184): spindown 7 (Routine)

Sep 5 05:32:48 Tower kernel: mdcmd (185): spindown 8 (Routine)

Sep 5 05:32:49 Tower kernel: mdcmd (186): spindown 9 (Routine)

Sep 5 05:32:49 Tower kernel: mdcmd (187): spindown 10 (Routine)

Sep 5 05:32:49 Tower kernel: mdcmd (188): spindown 11 (Routine)

 

I also checked the movie folder on each disk and only the disk that was written to has an updated timestamp so it does not even look like anything was written to any disk other than the one that got the file/s

Are you running cache_dirs?  If not then unRAID probably needs to spin up all the disks to decide where to place new files.  Even if you are running cache_dirs. then if you are running other add-ons that can use a lot of memory it is quite possible that the cache_dirs related buffers have been flushed and this the disks need spinning up.

 

Other settings such as restrictions on user share placement, split level and allocation methods could also influence this.

Are you running cache_dirs?  If not then unRAID probably needs to spin up all the disks to decide where to place new files.  Even if you are running cache_dirs. then if you are running other add-ons that can use a lot of memory it is quite possible that the cache_dirs related buffers have been flushed and this the disks need spinning up.

 

Other settings such as restrictions on user share placement, split level and allocation methods could also influence this.

 

I run cache dirs on that folder. nothing has changed since I upgraded from rc10 to 5.0  even if it wasn't cache dirs it would only need to spin up all the drives to get a list then start writing to one drive which means the other drives would spin down in 1 hour but they don't spin down till 1 hour after mover finishes.  Here is a previous syslog.

 

Jul 20 03:40:01 Tower logger: mover started

Jul 20 03:40:01 Tower logger: skipping Apps/

Jul 20 03:40:01 Tower logger: moving Movies/

Jul 20 03:40:01 Tower logger: ./Movies/BULLET_IN_THE_CACE.ISO

Jul 20 03:40:01 Tower logger: .d..t...... ./

Jul 20 03:40:01 Tower logger: .d..t...... Movies/

Jul 20 03:40:01 Tower logger: >f+++++++++ Movies/BULLET_IN_THE_CACE.ISO

Jul 20 03:54:56 Tower logger: ./Movies/TEAM_AMERICA_WORLD_MOLICE.ISO

Jul 20 03:54:56 Tower logger: .d..t...... ./

Jul 20 03:54:56 Tower logger: .d..t...... Movies/

Jul 20 03:54:56 Tower logger: >f+++++++++ Movies/TEAM_AMERICA_WORLD_MOLICE.ISO

Jul 20 04:09:31 Tower logger: ./Movies/

Jul 20 04:09:31 Tower logger: .d..t...... ./

Jul 20 04:09:31 Tower logger: .d..t...... Movies/

Jul 20 04:09:32 Tower logger: mover finished

Jul 20 05:10:00 Tower kernel: mdcmd (69): spindown 1

Jul 20 05:10:01 Tower kernel: mdcmd (70): spindown 11

Jul 20 05:10:21 Tower kernel: mdcmd (71): spindown 0

Jul 20 05:10:22 Tower kernel: mdcmd (72): spindown 10

Yes this is odd.  Are you using spinup groups?

No spin up groups

 

Last night

 

Sep 11 03:40:01 Tower logger: mover started

Sep 11 03:40:01 Tower logger: skipping Apps/

Sep 11 03:40:01 Tower logger: moving Movies/

Sep 11 03:40:01 Tower logger: ./Movies/THE_THIEVES.ISO

Sep 11 03:40:01 Tower logger: >f+++++++++ Movies/THE_CHIEVES.ISO

Sep 11 04:05:28 Tower logger: ./Movies/

Sep 11 04:05:28 Tower logger: mover finished

Sep 11 05:05:48 Tower kernel: mdcmd (266): spindown 0 (Routine)

Sep 11 05:07:30 Tower kernel: mdcmd (267): spindown 2 (Routine)

Sep 11 05:07:30 Tower kernel: mdcmd (268): spindown 11 (Routine)

Sep 11 05:07:41 Tower kernel: mdcmd (269): spindown 1 (Routine)

Sep 11 05:07:42 Tower kernel: mdcmd (270): spindown 3 (Routine)

Sep 11 05:07:42 Tower kernel: mdcmd (271): spindown 4 (Routine)

Sep 11 05:07:43 Tower kernel: mdcmd (272): spindown 5 (Routine)

Sep 11 05:07:44 Tower kernel: mdcmd (273): spindown 6 (Routine)

Sep 11 05:07:44 Tower kernel: mdcmd (274): spindown 7 (Routine)

Sep 11 05:07:45 Tower kernel: mdcmd (275): spindown 8 (Routine)

Sep 11 05:07:46 Tower kernel: mdcmd (276): spindown 9 (Routine)

Sep 11 05:07:46 Tower kernel: mdcmd (277): spindown 10 (Routine)

 

Any ideas where to stat looking??

My unRAID has always done this with or without running cache_dirs. I thought it was operating as designed.

 

Sep 10 03:45:09 malcolmplex logger: mover finished

Sep 10 04:00:16 malcolmplex kernel: mdcmd (81): spindown 0

Sep 10 04:00:27 malcolmplex kernel: mdcmd (82): spindown 1

Sep 10 04:00:27 malcolmplex kernel: mdcmd (83): spindown 2

Sep 10 04:00:27 malcolmplex kernel: mdcmd (84): spindown 3

Sep 10 04:00:28 malcolmplex kernel: mdcmd (85): spindown 4

Sep 10 04:00:29 malcolmplex kernel: mdcmd (86): spindown 5

Sep 10 04:00:30 malcolmplex kernel: mdcmd (87): spindown 6

Sep 10 04:00:30 malcolmplex kernel: mdcmd (88): spindown 7

Sep 10 04:00:30 malcolmplex kernel: mdcmd (89): spindown 8

Its issuing spindown but who says it was actually spinning?

Any ideas where to stat looking??

 

Here's something to try.  In the mover script,

/usr/local/sbin/mover

there is this line:

 

      -exec rsync -i -dIWRpEAXogtO --numeric-ids --inplace {} /mnt/user0/ \; -delete

 

Edit the script and get rid of the 'O' option, that is, make the line look like this:

 

      -exec rsync -i -dIWRpEAXogt --numeric-ids --inplace {} /mnt/user0/ \; -delete

 

Let me know if that makes any difference.

 

I tried to make that change and got an interpreter error when I let the mover run, I copied the backup file I created back over and manualy ran it, it's running now.  One thing I wanted to check is what disks were sinning and what is weird is the unraid gui says disks 9 10 cache and parity are spinning but uumenu says only 9 cache and parity so I'm not sure what is happening.  I will redo the modifications and retry.

Didn't make a difference, during actual file move disks 1, cache, parity and 9 were spinning after finished all disks spun up.

i am guessing here, the programming is not my strong suit (to put it mildly). but, going by my setup and update habits... i can see all or many hdd's spinning up. i add a lot of music every week, i delete also quite some (due to quality improvements etc). so, i push new stuff to cache drive, delete at the same time from existing collection.... (btw, if it matters - using waterfall mode). it doesn't surprise me that many (sometimes all) drives are spinning up while moving files. i would write that off to file replacement, check on db, parity upgrades. i experience the same or nearly all the time during mover activity. at the same time it just affect the drives of my music share. so all seems to be in normal parameters.

if you have a general 'all drives up' you might want to consider your share settings, spinup group settings etc. i have no spinup groups set myself. not really needed for my needs. saves on my powerbill  . also, my drives are set to spindown after 5min. that's low and poss. not a working setting for many ppl. it fits my needs. with a similar setup you should see drives during mover activity also spin down again.

 

Lars

Would not think setting smaller spin down time work as the drives all spin down 1 hour after the mover stops, if the other drives were spinning down before the ones that actually had the data written to them then yes.

 

What I have found is it does depend on the share level, and what drives have files at that share.  My movies for instance is a single folder with all files in the root spread a cross all drives.  When mover moves to this share, during the actual copy, only the parity cache and disk being written to are spinning on completion of the file transfer the other disks spin up.  On my other share for TV where split is set to 10 so files will be written anywhere, say a files is being moved to ncis/season 10/ during transfer only cache disk 1 parity and the disk data is being written but when complete all disks that contain files in that folder will spin up.

I'm still seeing this issue on 5.0  all disks only spin up after the copy of the file has completed so may be something to do with the modify time??  Anyone else getting this or just me??