How to determine cause of spin up

Hi fellow unRaiders,

 

I'm finding 2 disks (parity and disk1) in my array are constantly being spun down according to my syslog:

 

I'm not viewing anything and my spindown is set to one hour. I suspect it may be the slimserver that is running on disk1 but is there anyway to determine this and then prevent the disks being spun up?

 

thanks Josh

 

Nov 3 07:24:19 Tower kernel: mdcmd (15063): spindown 0
Nov 3 07:24:20 Tower kernel: mdcmd (15064): spindown 1
Nov 3 08:29:29 Tower kernel: mdcmd (15455): spindown 0
Nov 3 08:29:30 Tower kernel: mdcmd (15456): spindown 1
Nov 3 09:39:41 Tower kernel: mdcmd (15877): spindown 0
Nov 3 09:39:42 Tower kernel: mdcmd (15878): spindown 1
Nov 3 10:54:53 Tower kernel: mdcmd (16329): spindown 0
Nov 3 10:54:54 Tower kernel: mdcmd (16330): spindown 1
Nov 3 12:15:05 Tower kernel: mdcmd (16811): spindown 0
Nov 3 12:15:06 Tower kernel: mdcmd (16812): spindown 1
Nov 3 13:40:17 Tower kernel: mdcmd (17323): spindown 0
Nov 3 13:40:18 Tower kernel: mdcmd (17324): spindown 1
Nov 3 15:13:29 Tower kernel: mdcmd (17883): spindown 0
Nov 3 15:13:30 Tower kernel: mdcmd (17884): spindown 1
Nov 3 16:45:41 Tower kernel: mdcmd (18437): spindown 0
Nov 3 16:45:42 Tower kernel: mdcmd (18438): spindown 1
Nov 3 18:05:11 Tower kernel: mdcmd (18914): spindown 4  ----> This one I used as I watched something
Nov 3 18:51:30 Tower kernel: mdcmd (19192): spindown 0
Nov 3 18:51:31 Tower kernel: mdcmd (19193): spindown 1
Nov 3 19:10:44 Tower kernel: mdcmd (19329): spindown 0

 

 

I have the same problem:

 

http://lime-technology.com/forum/index.php?topic=8008.0

 

Check fuser and lsof on /mnt/disk1

lsof and fuser will only show files open at the time they are invoked.  They are useless unless you happen to invoke then at exactly the right instant in time.

 

I'd suggest instead the inotifywait tools.

 

To track activity under /mnt/user, type:

inotifywait -mr /mnt/user

To track activity on a specific disk (/mnt/disk1), type:

inotifywait -mr /mnt/disk1

 

You can download and install this through unMENU, as it is one of the available packages in the package manager, or

you can download from

http://www.slackware.org.il/slackware/slackware-12.2/slackware/a/inotify-tools-3.13-i486-1.tgz

put the downloaded file on your flash drive (in a "packages" directory to keep it consistent with other users)

 

To install it, log in as root and type:

installpkg /boot/packages/inotify-tools-3.13-i486-1.tgz

echo "100000" >/proc/sys/fs/inotify/max_user_watches

 

Once installed you can type

inotifywait -mr /mnt/disk1

to watch all the accesses on disk 1.

Yeah, but when a filesystem is busy and disk can't be spun down, then the process must be active at exactly the same time?!

 

However, notifywait is an excellent suggestion!

Yeah, but when a filesystem is busy and disk can't be spun down, then the process must be active at exactly the same time?!

<embarrassed> I knew that.... </embarrassed>

However, inotifywait is an excellent suggestion!

Besides, he said the disk was constantly being spun down, not that it could not be spun down.

Besides, he said the disk was constantly being spun down, not that it could not be spun down.

I thought this was a typo as he said slimserver was running. Hmm...

Thanks for the help so far.

 

I'll clarify a little.

 

I have slimserver (on disk1) running as:

perl slimserver.pl --daemon --user slimserver.

From my little understanding the --daemon command keeps it running doesn't it?

The squeezebox isn't actually on most of the time and accessing the music.

 

My disks can spin down and they do spin down, looking at the times it appears as if they spindown and then anywhere from 5 min to 30 min both the parity and disk one spin up and then an hour later spin down again. I'm assuming this as the spin down times are approx 1:05 to 1:30 apart.

 

I know they spin down as when I log in to the unRAID web menu it shows everything spun down. The difficulty I have catching it is that it seems random.

 

Theone: My problem is a little different to yours, your's appears to spindown constantly. Mine are at least 1 hour apart (my spindown time is 1 hour) which I assume means that everything works fine, it's just something is writing to disk1 so the parity and disk1 spin up again.

 

I'll install inotifywait through unMenu (fantastic app too BTW) and try the inotifywait in a few days as I'm away for a few days and see what that throws up.

 

Thanks Josh

SlimServer is accessing your disk1. Each time it logs it writes to it and parity disk spins up. You do not need to play music, only running SlimServer is enough for the system to not be able to spin down disk1.

 

I thought about overcoming this by using a small SSD and put on it permanent stuff like this. USB stick is theoretically also possible but too slow.

I suspected that it had something to do with slimserver because of the --daemon command.

 

Do you know what slimserver is logging?

Also why would a USB stick be too slow? USB2.0 has a pretty fast transfer rate.

 

thanks Josh

Do you know what slimserver is logging?

 

There is a server and scanner log.

 

Also why would a USB stick be too slow? USB2.0 has a pretty fast transfer rate.

 

Accessing USB memory is much, much slower than memory on SSDs (lots of faster chips in parallel).

I am not sure whether the log may be turned completely off and if SlimServer needs anything else.

Thanks starcat,

 

I will consult my friend google to see if I can turn off the logger or perhaps look into putting it somewhere else so I don't wear out those drives.

 

Thanks Josh

my input probably is a little dumb, but I, too, am having these constant spindowns - at least in the syslog, but my guess is I'm just reading it wrong. All disks are supposed to be spun down, and yet it gives me a spindown log every minute or so...I have nothing but unmenu running, afaik. unraid is not spinning the disks randomly up and down, is it?

 

Nov 4 14:25:57 Tower kernel: mdcmd (8823): spindown 3

Nov 4 14:25:57 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8834): spindown 0

Nov 4 14:26:58 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8835): spindown 1

Nov 4 14:26:58 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8836): spindown 2

Nov 4 14:26:58 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8837): spindown 3

Nov 4 14:26:58 Tower kernel:

It could be, and It could be unMenu causing it.

 

I have noticed on my test server that if i have myMain open and a refresh set for the page, every time it refreshes I get a disk spinup sound, quickly followed by a disk spindown.  I can look at the syslog and see this happening.

 

Now, this does not happen on my production server and I have been to lazy to figure out exactly why it is happening on my test server.  The one thing i do know is that one of the drives in my test server does not report a temp AT ALL, and smartctl seems to have little effect on it.  It is a very old IDE drive that i keep around purely for testing.  I have another older drive that i will probably be putting in its place as I believe it is a little newer and should report a temp.

It could be, and It could be unMenu causing it.

 

I have noticed on my test server that if i have myMain open and a refresh set for the page, every time it refreshes I get a disk spinup sound, quickly followed by a disk spindown.  I can look at the syslog and see this happening.

 

Now, this does not happen on my production server and I have been to lazy to figure out exactly why it is happening on my test server.  The one thing i do know is that one of the drives in my test server does not report a temp AT ALL, and smartctl seems to have little effect on it.  It is a very old IDE drive that i keep around purely for testing.  I have another older drive that i will probably be putting in its place as I believe it is a little newer and should report a temp.

 

I have this even if unMENU and any unRAID web page is not displayed at all.

 

my input probably is a little dumb, but I, too, am having these constant spindowns - at least in the syslog, but my guess is I'm just reading it wrong. All disks are supposed to be spun down, and yet it gives me a spindown log every minute or so...I have nothing but unmenu running, afaik. unraid is not spinning the disks randomly up and down, is it?

 

Nov 4 14:25:57 Tower kernel: mdcmd (8823): spindown 3

Nov 4 14:25:57 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8834): spindown 0

Nov 4 14:26:58 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8835): spindown 1

Nov 4 14:26:58 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8836): spindown 2

Nov 4 14:26:58 Tower kernel:

Nov 4 14:26:58 Tower kernel: mdcmd (8837): spindown 3

Nov 4 14:26:58 Tower kernel:

The older versions of unMENU used hdparm to determine if a drive is spinning or not.  a side effect of a bug in it is that it could spin up the drive when testing to see if it is spun up.  Or, it could be that lime-tech's code sees the disk being queried by hdparm, and even if it is not spun up, it thinks it is, so it spins it down again.

 

I had modified unMENU last August to use the spin time-stamps in /proc/mdcmd a while ago.  are you using an earlier version of unMENU?  (if not, you might want to update to the current version.)

Current version looks like this on the "About" link: unmenu.awk: Version 1.3 Revision: 139

I just checked, and I indeed have Rev.139. But as I said, I have no idea what's causing it (if indeed it is really spinning up and down, or just displaying it like it was), and unmenu is the only other thing I have running. rsync, too, but I've never invoked it, as far as I know.

I just checked, and I indeed have Rev.139. But as I said, I have no idea what's causing it (if indeed it is really spinning up and down, or just displaying it like it was), and unmenu is the only other thing I have running. rsync, too, but I've never invoked it, as far as I know.

Are you running any other scripts or packages?  (hourly status checks?  temperature warnings?  last_io script on mover?)

 

Joe L.

no, zilch.

Of course, now that I'm intently looking at it, it seems to be not doing it (at least for the past half hour or so) - "Vorführeffekt" as we call it in German 

no, zilch.

Of course, now that I'm intently looking at it, it seems to be not doing it (at least for the past half hour or so) - "Vorführeffekt" as we call it in German 

 

I had it doing the continuous spin-down thing randomly sometime 2-3 times a day and sometime one a week - each time several times.

 

Shouldn't there be a counter to eliminate this even if something did spin up the drives they should spin down until the timeout is reached - mine was set to 3 hours.

 

This is one of the reasons I have stopped using the spin-down at all.

 

 

 

no, zilch.

Of course, now that I'm intently looking at it, it seems to be not doing it (at least for the past half hour or so) - "Vorführeffekt" as we call it in German 

 

I had it doing the continuous spin-down thing randomly sometime 2-3 times a day and sometime one a week - each time several times.

 

Shouldn't there be a counter to eliminate this even if something did spin up the drives they should spin down until the timeout is reached - mine was set to 3 hours.

 

This is one of the reasons I have stopped using the spin-down at all.

 

 

 

Just to complicate the issue, some drives do periodic self-tests when otherwise idle.  They call them "offline tests."    It all depends on the drive firmware.