I've been a bit disgruntled with the long spin-ups as my system grew to 14 disks.  My media PC and extenders routinely timeout while waiting for the unraid to spin everything up when trying to access content.  I read a post on here that the problem is the user shares and that the system doesn't know which drive the file being accessed is on and spins up all the drives (or all the drives until it finds it maybe?).

 

Seemed to make sense, so I spent A LOT of time (surprising how long it takes to move around 9 or 10TB of data) completely revamping my disk layouts and user shares.  Instead of every disk having a movies/genre/movie layout with just one movies user share, I now have a genre/movie layout with a user share for each genre.  Each genre fits on one disk, so as of now, each user share is set to only "include" the disk that the genre resides on.  So since there is only one disk in the user share, when accessing content on a user share, it should only have to spin up that one disk.

 

Wrong.  I just tried to access a single user share and after waiting an inordinate amount of time I pulled up the web console and it showed that it had spun up 7 of my 10 data disks (in the consolidation I also upgraded a few drives and dropped down from 14).

 

So why is it sitting there spinning up extra disks when it should know exactly where the files are?  The long spin up times are really reducing the WAF of this whole setup.  Thanks for any insight.

Instead of using user shares, use symlinks.

 

on disk1 mkdir /movies

 

inside /movies make a dir "a-k"

inside /movies make a dir "l-r"  and symlink it to /disk2

inside /movies make a dir "s-z"  and symlink it to /disk3

 

or whatever letters will work for your distribution of film titles.  You can rename them at any time if needed.

 

I do this with 9 drives, and you will generally never need to spin up more than 2 drives (drive 1 and the drive where you are browsing the symlink)

Ok but why does it take so long for his disks to spin up?  mine dont ever take that long and i have pretty much the same setup.  Video share and in that, genre folders.  in those folders are just a bunch of .iso's.

I just sat down to test this some more and got some mixed results.  First off, I hit "spin down" to, well, spin down everything.  That took about a minute which seemed excessive.  I opened a user share and it only spun up the one disk it resides on.

 

I hit "spin down" again and this time it took forever, probably at least 5 minutes!  I'm sure that's not normal.  I telneted in during this to check the syslog and it kept giving the following over and over:

 

Jan  6 01:28:03 WatchTower emhttp: shcmd (147): sync

Jan  6 01:29:19 WatchTower emhttp: shcmd (148): /usr/sbin/hdparm -y /dev/sdk >/dev/null

Jan  6 01:29:19 WatchTower emhttp: shcmd (149): /usr/sbin/hdparm -y /dev/sdl >/dev/null

Jan  6 01:29:19 WatchTower emhttp: shcmd (150): /usr/sbin/hdparm -y /dev/sdm >/dev/null

 

Except it listed all the disks and I just included a few for demonstration.  I tail'd the syslog and these repeated several times with about 1.5 minutes between the sync messages.  Anyone know what is going on here?  I'm wondering now if there is something bad going on that is causing the long spin ups and spin downs.

 

In any case I tried a few more user shares but most of them were cached and didn't spin up the disks, I couldn't repeat it spinning up more than one disk at a time but it definitely did it earlier because the system hadn't been used in many hours and as I said it took a long time to spin up and 7 disks were shown spun up.

The Spindown button, when some disks are already spun down, will spin them all back up, and then back down.

 

This is because a "sync" command is done, which spins up a spun-down drive.

 

Cest la vie.

It looks like it took a minute and 16 seconds for the sync to finish, which does seem excessive.  The other lines are the normal spin down commands (hdparm -y DRIVE_SYMBOL) to the individual drives, one for every drive including the parity drive and cache drive.  In this case, you showed 3 of the lines, for your drives sdk, sdl, and sdm.  They are completely normal.

 

There's not enough info here to make any conclusions.  Were there any drive errors listed in the syslog?  You might post it here, and tell us which version of unRAID you are running, and some detail about your hardware.

 

There have been a number of changes made in recent unRAID versions concerning spin down, so trying a different version may make a difference.

Well, I prepared the below post, but it isn't allowing me to attach the log.  It is only 94k and under 20k zipped, but when I try to attach it I get the following:

 

Your attachment couldn't be saved. This might happen because it took too long to upload or the file is bigger than the server will allow.

 

Please consult your server administrator for more information.

 

Anyone know what is going on?

 

**********

 

Thanks Rob, I've attached my log.  I don't see any hardware errors, but it's possible I missed something.  I'm running 4.4, I have all SATA 3.0 drives from 500GB to 1.5TB, plus a 250GB cache drive.  I have 2 Promise SATA PCI cards, one Adaptec PCIe card, and the MB SATA connectors.

 

Let me run through what happened.  In the log at Jan 6 01:21:19, I hit the spin-down button and it looks like it took about a minute 5 seconds to complete.  I then did one of my tests, hit the spin-down button again at Jan 6 01:22:51, and a couple minutes later I was still waiting and I telneted in at Jan 6 01:25:36, so it had been running already for 2 and a half minutes.  I don't think it ended until Jan 6 01:29:22, about 6 and a half minutes after it started, but according to how you described the log messages, the weird thing is that even though I only hit the button once, it looks like it repeatedly called sync 4 or 5 times.

 

Admittedly I was impatient and hit refresh on the browser and tried to pull up other pages, but that shouldn't restart the spin-down process right?

 

I still can't get the attachment to work, let's try this:

 

http://www.diligentmed.com/other/syslog.txt

On a related note, I was just watching some recorded TV shows which is on disk 4, so it had to have been spun up.  I was going to do some housekeeping for the show files, and I pulled disk4 up in Windows Explorer and it took quite a while to give a directory display, so I pulled up the web console and it showed that several other disks were being spun up.  Why is it spinning up other disks, this time I wasn't even using a user share, I went directly to disk4.

 

I pulled up the log and there are no log entries for the last couple hours, so nothing about this was logged.

Windows Explorer, thinking it is helping you, was probably scanning the drives, even if you only went to disk1.

 

Joe L.

..., the weird thing is that even though I only hit the button once, it looks like it repeatedly called sync 4 or 5 times.

 

Admittedly I was impatient and hit refresh on the browser and tried to pull up other pages, but that shouldn't restart the spin-down process right?

 

This *might* be another case similar to the one in the past where a shutdown of the array could occur in certain cases of refreshes of the web page, don't remember the details.  Joe could possibly figure out, if refreshing this web page, it also re-sends or re-POST's (?) the command to spin down all drives.

Ok, I can buy that.  So then let me just ask if a sync command taking a minute to a minute 20 with 12 drives in the array is out of the norm.  If it is, is there anything that I try to do to speed it up?  The long spin-ups are a problem for my media PC and extenders since they are always on (I've seen the script to spin up when a device is turned on but that isn't any help to me).

 

Thanks.

You could try something like I now use.

This script is called "frequent_ls.sh" and I invoke it whenever I reboot my server. (It is invoked by a script at the end of my "go" script)  You can experiment by invoking it on the command line.

 

 

#!/bin/sh

crontab -l >/tmp/crontab

grep -q "frequent ls" /tmp/crontab 1>/dev/null 2>&1

if [ "$?" = "1" ]

then

    echo "# frequent ls to keep directory blocks in memory:" >>/tmp/crontab

    echo "* * * * * for i in 1 2 3 4 5 ;do sleep 10; test -d /mnt/user/Movies || exit; ls -R /mnt/user/Movies  1>/dev/null 2>&1; done" >>/tmp/crontab

    crontab /tmp/crontab

fi

 

On my server, all my movies are under /mnt/user/Movies  with "Movies" being the "user-share" I see on the LAN.  If you have a different structure you can change the command as appropriate.  (Let me know what your top level "media" share(s) is/are and I can guide you on how to change the script)

 

With this script running the directory blocks for all the movie listings are kept in RAM since they are frequently used.

 

Joe L.

Joe,  I do have something similar in my startup script to cache the directories, although I don't have a cron job to refresh it so once it gets flushed, it is gone.  I will update it to include the cron job, thanks!

 

To be honest though, the problem isn't so much the directory browsing as waiting for the drives to spin up when I want to access media.  Since the media PC and extenders are always on, I can't just look for them on the network as a hint to spin up the drives.  I've started writing a WMI program that will send a spinup command when certain applications are started on the media pc, that would be perfect.  The problem is that media center runs add-on programs in a shell, so all add-ons have the same process name.  I haven't gotten far enough into it to determine if I can get further information on the process to see if a new process is the add-on I'm interested in.

 

If I can get it working, I'll post here for anyone else that is interested in this for their media PC's as well.

Are spin ups and spin downs actually logged anywhere?  ... I can see in the syslog where the hdparm command runs to initiate a spindown but is there an actual event log somewhere that records that the spindown was successful, and when a spinup for a device occurred?

 

Are spin ups and spin downs actually logged anywhere?  ... I can see in the syslog where the hdparm command runs to initiate a spindown but is there an actual event log somewhere that records that the spindown was successful, and when a spinup for a device occurred?

 

A spin up occurs whenever a disk block is read while it is sleeping.  No log of it occurs.  As far as I know, nothing monitors if a spin-down command is successful either.

 

unRAID is currently monitoring disk I/O statistics to learn when a disk is being accessed.  That acrivity on a given disk resets its timeout timer used to put it to spin it down.

 

Joe L.