Hello,

 

the "spin up" button introduced in 4.2 works very well/fast. However, when I access a share which spreads over multiple discs, unRAID spins up one disc after the other, taking about 10 seconds per disc. Now my suggestion would be to spin up all needed discs at once in this situation, similar to how the "spin up" button works.

 

Thanks!

Actually, the staggered/serial spinup is much more desirable, as it prevents the large current surge you would have otherwise.  Spinning them all up at once can cause your system to crash.  10 drives will easily pull over 300 EXTRA Watts if they all spun up at the same time.

Actually, the staggered/serial spinup is much more desirable, as it prevents the large current surge you would have otherwise.  Spinning them all up at once can cause your system to crash.  10 drives will easily pull over 300 EXTRA Watts if they all spun up at the same time.

Then why is there a "spin up all drives" button on the main page of the web interface? It seems to work well for me. If spinning up all drives at once is really dangerous, maybe it would make sense to add an option to switch that behaviour on/off?

 

It does go on my nerves if I access a share and all drives are down and unRAID spins up all my 10 data drives one after the other while taking up to 10 seconds per drive. It means I have to wait up to 1.5 minutes until I can really access that share...

P.S: Even if spinup of all discs is problematic, I still see lots of improvement potential. E.g.:

 

(1) unRAID could always spin up 2-3 discs at a time. That should not be too hard on the power supply and still cut the waiting time by 2x/3x.

(2) unRAID could spin up the discs with a delay of 1 second for each drive instead of the current 10 seconds. Then the overall waiting time would be "10 + numberOfDiscs - 1" seconds instead of "10 * numberOfDiscs" seconds.

The problem is that when you spread a share across multiple disks, unRAID does not know WHICH disk the data you want is on.  Spinup is done at a very low level -- unRAID doesn't spin it up, the driver does and it does it when the drive is accessed.  An application like Samba, merely accesses the drive and doesn't care if the drive is spun up or down... the driver will spin it up if necessary.  But when it encounters a spundown drive, it waits for it to report ready before proceeding.

 

The "Spin up all drives" in the UI, does stagger the spinup IIRC, but that stagger is shorter because it does not wait for a drive to report ready before moving to the next one.

 

There was a script posted a while back that would poll an IP and then spin up all the drives when that IP was active.  Perhaps you can use that.  Otherwise, you could just disable spindown, or sent it to an 8 hour spindown time.

Of course I don't know all the dirty details of the internal unRAID implementation. Might well be that you're right and that unRAID couldn't implement my improvement suggestion efficiently. I just think that a spin up time of 1.5 minutes is not really a good thing and that there might be interest in improving this. Maybe Tom has an idea about how he could realize that?

 

I'm aware of the available workarounds but not spinning down the disks at all is really not acceptable. And letting them run 8 hours isn't, either. The spin down logic of unRAID is one of the big advantages of unRAID for me. So I will surely not compromise there.

 

I can live with the current solution. It works. It's just a bit frustrating if you access a share and sometimes have to wait 1.5 minutes before you can really access it. That's why I posted my improvement suggestion...

a solution could be that simultaneous spin-up were an option.

So if one has sufficient powered powersupplys a faster response time can be achieved.

However I suspect that lots of users with borderline sufficient, would choose the option, and not understand why the server fails when the threshold is exceeded.

/Rene

The other option is to not use user shares.  If you want user shares, you have to accept the fact that when you access the share, the following happens:

 

for each drive:

1) query drive

2) the query causes spinup

3) data is returned after about 10 seconds

4) go to next drive if needed.

 

I suspect that data retrieved from the first query MUST be returned before the next query can be issued.

 

Remember, unRAID does not keep track of what drives are spun up or down.  Only the admin interface accesses that info and does it with a command only on user request.

 

Even a "spin up all drives when any drive is accessed" would require some hooks to be placed in the driver.  Driver mods like that take a great deal of testing and QC.

@bubbaQ, where do you have these detailed information from? Do you have the unRAID source code?

 

I'm wondering: We can tell unRAID after which time of idleness each harddisk may be spun down. This is done on the fly, so doesn't unRAID *have* to keep track of which drive was accessed at which time and which drive is spun up and down?

@bubbaQ, where do you have these detailed information from? Do you have the unRAID source code?

 

We all have at least some of the source code.  Look in /usr/src.  I don't think the admin screens are in there, though.

 

 

Bill

No, unRAID does not spin down the drives "on the fly."  It issues a command (hdparm) _once_ to the drives, telling them to spin down after a specified amount of inactivity time.  The low-level driver takes care of it from then on.

Ok, thanks Bill and bubbaQ, didn't know that.

 

I've never done any linux programming yet, so I can't really judge how difficult my suggestion would be to realize. However, I do have a (tiny) bit of windows driver programming experience and I can say that it's no rocket science for a windows driver to get notified about file system accesses. So I'm not sure if it's really all that difficult for a linux driver to be notified about samba accesses.

 

Anyway, I find it a bit funny that we users are sitting here debating about how difficult a feature suggestion would be to implement and which problems it could eventually make. Not one of you guys has as of yet commented on whether the spin up delay (when using user shares with unRAID 4.2) bothers you or not. Or how much of an improvement you would consider an improvement in the spin up delay to be. Shouldn't that be the main discussion point in this thread? Shouldn't we leave it up to Tom to decide how difficult/dangerous it would be to implement the improvement suggestion and whether it's worth it? Tom will only be able to decide whether it's worth it, if we users talk about how important an improvement would be for us. So would you guys mind to comment on your opinion about the usefulness (or uselessness) of an improvement in spin up delay?

 

Thanks!! 

spinup delay, no problem

/Rene

To answer your question, I don't have any problem with the current spin-up delays.  Perfectly acceptable to me.

Ok, thanks guys.

 

Seemingly I'm the only one bothered by 1.5 minutes spin up delay...  :'(

 

(That said, I'm quite happy with unRAID.)

I had an issue with the spin-up delay... you are not alone...

 

BUT... it was not the wait, but the effect the delay had on my media player.  It timed out waiting for the response.  I then had to reset it back to its starting menu to have it re-scan my LAN for shares, and then after selecting a share, re-scan it for media files.  This was way worse than having to wait for the list of files.

 

I created a script to run on the unRaid server that looks to see if either of my MG-35 media players are on-line. If either is, all my disks are spun up by reading several random blocks of data from them.  Once the Media-players are turned off and are no longer detected on my LAN, the disks eventually time out and go back to sleep.

 

This thread describes the script I wrote.

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

 

The script went through some iterations as it stopped working when Tom added some additional security and the management page could be password protected.  I also found one of the tests the script was making did not always return the expected result... so I simply made the test a different way.

 

The script does require that your media players have fixed IP addresses.  Most can be configured for fixed IP addresses, so you should not have too much of an issue.

 

The instructions on how to add the script and invoke it are in the first post in that same thread.  It no longer needs "netcat" to function as it does not access the web-based front end any longer. (the original version did actually press the spin-up button on the web-page for you.  Now, it simply accesses the disks themselves and lets the disk driver do the spin up)

 

Joe L.

Thanks Joe. Looks like quite an interesting script...    Currently I'm using a HTPC which is always on so the script doesn't help me much right now, but maybe I'll replace my HTPC with a media player box somewhen...

You might experiment with the smbstatus command.  If it can show you file access before spinning up all the drives it might be possible to replace the "ping" in my script with a line or two invoking smbstatus and using egrep to look for a specific folder or folders being accessed.

 

To experiment telnet in...

type smbstatus before accessing your media.

 

Start a media search from the HTPC

 

As soon as it starts, and before all the drives are spun up, type smbstatus again.

 

See if the file access shows up there before the other drives are spun up.  If so, an alternate script is easy to put together.

The entire function to check status would then be something like this:

 

check_mp_status() {

    # assume media player is off-line till we know otherwise

    mp_online="no"

 

    # mp is on-line if media from these drives is being accessed.

    # A pipe "|" delimited listing of the top level folders holding your media.

    media_shares="/mnt/Movies|/mnt/MP3|/mnt/TV Shows"

 

    out=`smbstatus`

    rec_count=`echo "$out" | egrep "$media_shares" | wc -l`

    if [ "$rec_count" -gt "0" ]

    then

        mp_online="yes"

    fi

    echo "$mp_online"

}

Perhaps overly obvious, but you could try not creating situations where the same folder is on so many drives.  Perhaps have movies1, movies2, movies3 and then only have 30 seconds per spinup.

 

 

Bill

If you can have your HTPC invoke one web-page prior to browsing your media, you could simply put this as a "shortcut" on a browser:

 

http://tower/main.htm?cmdSpinUpAll=Spin%20up 

 

It is the same as pressing the spin-up button on the web-interface.

 

Joe L.

You might experiment with the smbstatus command.  If it can show you file access before spinning up all the drives it might be possible to replace the "ping" in my script with a line or two invoking smbstatus and using egrep to look for a specific folder or folders being accessed.

 

To experiment telnet in...

type smbstatus before accessing your media.

 

Start a media search from the HTPC

 

As soon as it starts, and before all the drives are spun up, type smbstatus again.

 

See if the file access shows up there before the other drives are spun up.  If so, an alternate script is easy to put together.

 

Thanks much! I'll give this a shot in the next few days.

 

Perhaps overly obvious, but you could try not creating situations where the same folder is on so many drives.  Perhaps have movies1, movies2, movies3 and then only have 30 seconds per spinup.

 

The thing is, I don't really want any compromise in functionality.

 

If you can have your HTPC invoke one web-page prior to browsing your media, you could simply put this as a "shortcut" on a browser:

 

http://tower/main.htm?cmdSpinUpAll=Spin%20up 

 

It is the same as pressing the spin-up button on the web-interface.

 

Thank you, that's helpful. Not as nice as having an automatic spin up of the needed disks, but at least it's an improvement without any real drawbacks.

I believe the answer to the above (except for the special problem that Joe has addressed) is improved directory caching.  Caching of the directories of the physical disks is straight-forward, and I believe Tom has this high on his feature list, but caching of the User Shares is probably somewhat more complex, and may be harder to implement.  But once the logical 'directories' of a User Share are cached, with the actual physical disk location of each file, then only the desired drive(s) will spin up, and you should never have to spin them all up, searching for files.

 

I believe the answer to the above (except for the special problem that Joe has addressed) is improved directory caching.  Caching of the directories of the physical disks is straight-forward, and I believe Tom has this high on his feature list, but caching of the User Shares is probably somewhat more complex, and may be harder to implement.  But once the logical 'directories' of a User Share are cached, with the actual physical disk location of each file, then only the desired drive(s) will spin up, and you should never have to spin them all up, searching for files.

Well, that would be great, of course!