I have one SSD installed in my server, that I purchased to have one storage location with a fast response time that didn't sleep.  It's used for a Media jukebox database I don't want to wait for it to "wakeup" when called for.

 

I don't think SSD's truly sleep as they are not mechanical, but I changed the settings for disk 9 to "never."  When I was in 4.7 and I think rc3, this seemed to work fine.  I never had a latent response from my media player when it tried to access this share.  I'm noticing on rc4 at least it is much slower at times when the server has been sitting idle.  15-20 seconds maybe more.  Other times it's instantaneous.  I think rc3 acted more like 4.7, but am not 100% on this. 

 

Does unRAID as a whole eventually go to a sleep mode?  Is there a setting where you can tell it not to or change settings? 

 

Attached are screen shots of my current settings.  If you think my syslog is important to this question let me know but I wasn't thinking so.

 

Anyone have thoughts on this? 

 

The more I pay attention, the more I think it is something in unRAID going to sleep.  Either the whole server or the drive for some reason.  If there is little time since the last access to that folder it is very quick.  If not there is a long lag. 

 

I did try changing spin up groups based on how my shares were set up.  IE I put drives housing the same share into the same spin up group.  Could this be  spin up group issue?  I wouldn't think so since I set the drive in question to never spin down, but if for some reason it's trying to spin up other drives before allowing access, could that cause it? 

 

What happens if I disable spin up groups?  Would that mean each drive spins up individually?  If so maybe that could determine if it's the answer.

I don't have any SSD's, so perhaps I'm not the most knowledgeable here, but I can get the ball rolling, and perhaps others will chime in.

 

UnRAID does not have a sleep option.  There are tools in certain addons that can assist in supporting sleep functions, but only if your hardware fully supports sleep.

 

I have never heard of any sleep functionality in connection to SSD's, so I think any sleep related settings would be ignored, and they should always respond immediately.  I have no idea why you would see any changes in response or performance.  Ordinary hard drives can spin down, a form of sleep, and when spun up, can cause system-wide delays of 4 to roughly 8 seconds.  Is it possible that that is what you are seeing?  You would probably never want an SSD to be in a spin up group with other drives (at least, I don't think so).

 

Edit:  And no, I'm pretty sure this has nothing to do with a specific RC.

I don't have any SSD's, so perhaps I'm not the most knowledgeable here, but I can get the ball rolling, and perhaps others will chime in.

 

UnRAID does not have a sleep option.  There are tools in certain addons that can assist in supporting sleep functions, but only if your hardware fully supports sleep.

 

I have never heard of any sleep functionality in connection to SSD's, so I think any sleep related settings would be ignored, and they should always respond immediately.  I have no idea why you would see any changes in response or performance.  Ordinary hard drives can spin down, a form of sleep, and when spun up, can cause system-wide delays of 4 to roughly 8 seconds.  Is it possible that that is what you are seeing?  You would probably never want an SSD to be in a spin up group with other drives (at least, I don't think so).

 

Edit:  And no, I'm pretty sure this has nothing to do with a specific RC.

 

Yes I was more referrIng to hard drive spin down and sleep would refer more to the whole sever.  Obviously I wouldn't expect a SSD to "spin down" and that is why I bought one in this case. 

 

However something has recently changed.  It used to be pretty instantaneous and definitely is not anymore.  The only thing that makes any sense to me is somehow it is connected with a spin up group and is spinning up other drives before coming online.  Is there a restore or original defaults that would include my original spIn up groups?

 

Any other thoughts are appreciated.  Thanks!

The concept of spinning up/down an SSD does not apply.  There is nothing spinning in an SSD. One could imagine a sleep mode for an SSD where it goes into a reduced power state (consumed power) but I have never read about anything like that; a "green SSD".

I believe he is merely stating that access to the SSD drive hesitates, where before it was instant. Thus giving him the impression that unRAID is waiting on something before allowing access to the SSD drive, behavior seen in a mechanical drive that has gone to sleep and requires to spin up (delay).

 

Tom, has made some changes, and there is no true support for SSD's yet. So it is possible that there is some sort of code that is not compliant with an SSD drive. Maybe timing out on a command being issued which an SSD can't comply with, etc.

 

It would be more helpfully, if you could state what is the drive set to be (ex. Data or cache drive) and what types of shares are you using with it (user shares, cache only, both, etc). How are you accessing it when you see this delay (ex. Windows explorer access to cache only share / media device running xyz, accessing user share to play a mkv movie...)

 

 

Also a tail trace showing what went on at the time you went to reproduce the behavior would help as well.

Have you verified no spinning drives have woken up when you notice the delay? Can you duplicate it by first using the "spin down" button, then accessing the SSD share?

 

It could be something else entirely but I'm thinking of the possibility one of your SSD shares includes a spinner, and even if there aren't any files there yet it could wake an uncached spinner when checking the share directory.

 

Look for hdparm messages around when the delay occurred. Or, post the syslog and let us know when you saw the delay.

 

I could also see a driver or even filesystem code defensively flushing anything queued, causing drives to spin up (and block progress) when you access the SSD. Buffering problems are often caused by not writing often enough so that kind of thing gets thrown in as an easy fix. The effect on your configuration would be much less frequently encountered.

 

Just a thought.

 

Maybe try connecting the ssd to a separate controller from all spinners?

Thanks for the replies.  Sorry I didn't get back on here sooner, but have been out of town.

 

The drive is a data drive, only 32GB, and holds the Zappiti menu system files that I access from my Dune media player.  If you are not familiar, Zapptit is a "jukebox" style menu system for the Dune and this is a very large collection of very small files used to create the menu structure.  The access is via a user share.

 

I have typically noticed this behavior first thing in the morning or after unRAID has been sitting for a few hours.  After reading this, I tried to spin down the drives and then access from the Dune.  I had been watching a movie at the time so prior to spin down everything was active.  I rebooted the dune so any cached data was cleared. 

 

With all drives spun down, a fresh start on the dune, but unRAiD recently used, the access was very fast, no latency or delay.

 

Tomorrow morning I will try this again and see what happens.  I tried the above experiment with spin up groups both disabled and enabled.  For the moment I have disabled spin up groups because previously it was enabled.  I totally understand a SSD does not spin up.  This is the whole reason I bought it.  The only thought I had was that it was waiting on other drives to spin up before allowing access (a group), but I have no idea to be sure.  I will post the results on here and capture the syslog if there is a problem.

 

Thanks, hopefully we can figure it out.

I could also see a driver or even filesystem code defensively flushing anything queued, causing drives to spin up (and block progress) when you access the SSD. Buffering problems are often caused by not writing often enough so that kind of thing gets thrown in as an easy fix. The effect on your configuration would be much less frequently encountered.

 

Just a thought.

 

Maybe try connecting the ssd to a separate controller from all spinners?

 

How would you diagnose or solve a buffering issue?

 

I do have one 2 port controller I could connect the SSD to alone.  Depending on what I find tomorrow I will try that next.  Good idea.  Right now it is connected to my supermicro card with 5 other drives.

This morning with spin up groups disabled, everything came up fine.  No delay.

 

I turned on spin up grips and likewise no delay.

 

So now I am puzzled, though pleased.  This was a consistent problem for several days or a week before I reported it.  Glad it is working now like it used to but not sure what fixed it.  The only thing I have done in all this time is turn spin up groups off and on.

 

If it comes back I will resurrect his thread.  I will watch it for a few more days before I mark this solved.

 

Thanks

How would you diagnose or solve a buffering issue?

This side of the code, I don't. I was speculating from experience a million years ago as a developer. It's usually much simpler to "fix" buffering/synchronization issues by forcing writes than removing them, and that's possibly what happened between releases. It wouldn't create a functional problem other than your demand for no delay on a system with drives sleeping. Looking at the rest of the industry this seems to be an unusual configuration, unfortunately.

 

Go back and see if you can duplicate the problem by forcing the drives to spin down then accessing your db. If it happens look in syslog for which drives are being spun up when you access the ssd. Follow the trail.

 

I do have one 2 port controller I could connect the SSD to alone.  Depending on what I find tomorrow I will try that next.  Good idea.  Right now it is connected to my supermicro card with 5 other drives.

 

Worth a try. Use the same tests with the current config and with the separate controller.

This morning with spin up groups disabled, everything came up fine.  No delay.

 

I turned on spin up grips and likewise no delay.

 

So now I am puzzled, though pleased.  This was a consistent problem for several days or a week before I reported it.  Glad it is working now like it used to but not sure what fixed it.  The only thing I have done in all this time is turn spin up groups off and on.

 

If it comes back I will resurrect his thread.  I will watch it for a few more days before I mark this solved.

 

This was without any other change in hardware or unraid config? Hate it when that happens.

 

This was without any other change in hardware or unraid config? Hate it when that happens.

 

Yes, I know  but at least it's working. 

 

This hasn't been a problem for a couple days now, so I'm going to to ahead and mark this resolved.  If it comes back I will resurrect.