I have asked about this problem once before and in the end had no real definitive answer because it just disappeared (with RC-4). 

 

I have a SSD that I use to house a specific group of files that I wanted to access without the spin up time hesitation.  I first installed the SSD under 4.7 and everything worked fine.

I first upgraded to 5.0 under RC-3 and noted that when the server had been sitting idle (unsure of how long) or overnight, if I tried to access the SSD first, it hesitated like it was spinning up or waiting for other drives to spin up (obviously SSD's don't spin up). It didn't occur when there wasn't idle time for the server.  This is when i first reported this issue here.  I experimented with spinup groups assuming the problem was other drives spinning up before it allowed access to the SSD, trying it with spinup groups off and having the SSD in it's own spinup group.

None of that worked, but when I upgraded to RC-4 it ended up going away and I reported the problem solved. 

 

Shortly after it's release I upgraded to RC-5, and over time noticed this problem was consistently back.  I haven't had time until recently to play with it again, and looked at the same set of spinup group combinations but never could get it to go away.  Last night I downgraded back to RC-4 and this morning everything started up without hesitation again.  I currently have spinup groups enabled and the SSD in it's own group.  The only thing I wish I had looked at under RC-5 is yesterday morning when I first start up if other drives were spinning up when I accessed the SSD, IE see if I could confirm the problem was other drives trying to spin up at the same time or if it is another issue.  I may go back to RC-5 tonight and see if I can check this in the morning.

 

I have not tried RC-6 yet since it wasn't put out for general consumption yet.  Is there any reason to think this would go away in RC-6? 

 

This is such a minor and fairly obscure glitch it may not get noticed by too many people.  I hope it can somehow get addressed when we get to a final 5.0 release.  Let me know if you have any ideas for me to try or if there is any testing I can do to help. 

 

Keep in mind any test, requires things to sit for an undetermined period of time.  It definitely happens during the day, but I really never have been able to tell just how long it has to sit idle.  If it really is a spin up group issue, it should only be the spindown time which isn't long at all.  However I seem to recall in my past round of testing, I tried to manually spin down the drives and then access the SSD without issue.  This is what made testing so difficult.  The only time I know confidently that it works is if it sits overnight, greatly slowing down the process.

 

EDIT: There were no entries in the syslog this morning when I accessed the SSD.  After I booted this PC to post this thread the mapping of network drives triggers most of the drives to spin up, and the only syslog entries are when those spin back down. 

Also the configuration in my signature is accurate except for me being on RC-4 currently.

Is the SSD set to never spin-down?

Is the SSD set to never spin-down?

 

Yes it is.  Should have mentioned that.

Is the SSD set to never spin-down?

 

Yes it is.  Should have mentioned that.

Is it naturally in its own spin-up group?  Or does it share a controller that waits on OTHER disks,and therefore would normally be in the same spin-up-group as other disks?

Is it naturally in its own spin-up group?  Or does it share a controller that waits on OTHER disks,and therefore would normally be in the same spin-up-group as other disks?

 

OK i remember reading something about that before.

 

I am pretty sure the SSd is on my Supermicro AOC-SASLP-MV8 controller card.  Do you think that could be the problem given it was an issue in RC3 and RC5, but not RC4?

 

Let me know if you have any thoughts, but tonight I will go back to RC5 and put the SSD on a dual port controller card that is currently unused.  If that does solve it, I  can leave it there permanently.  I really don't need that card for anything else.

 

Can you explain this to me a little better.  With my Supermicro card (8-ports on 2 cables), should it be making me wait for all 4 on the cable for a given drive to spin up?  Or all 8 on the card?  What about the other lard ports?

 

I don't think that is actually happening.  Things appear to be spinning up based on the groups that I created, not based on how they are connected to cables and cards.

 

Thanks for any help.

Ok I didn't even have to wait until morning on this. 

 

I put the SSD on an unused card by itself.  Upgraded back to RC5.  Restarted. 

 

After letting it sit for about 30 minutes, I tried to access the SSD again.  There was a long pause, before I could access it.  I checked and 5 drives had spun up so that must be what it is waiting on.  The question is why is it spinning up the other drives at he same time, and why in RC3 & RC5, but RC4 did not have this problem, as 4.7 didn't either?

 

 

Something I did notice, everything that is spinning up also contains the same user share folder.  The drives that aren't spinning up do not contain that user share. 

 

In other words, I have a user share that spans 6 drives.  One of them is this SSD and it contains a subfolder under that user share that's unique to that drive.  There is another subfolder unique to one of the other 5, and a third subfolder that spans the other 4 drives.  My spin up groups are set up to follow the same groupings as those subfolders.  When I access the SSD in RC5, the other 5 drives with that share are spinning up before I can access the SSD.  In RC4 it is not spinning those other drives first.  The other two data drives in my array are different user shares and different spin up groups as well.

 

 

Was there a change in the way user shares are accessed or ow spin up groups are managed between these different versions?

 

Thanks again.

 

 

do not confuse spin-up-groups with user-shares.  They have nothing to do with each other.

 

If all disks involved with a user-share that is on the SSD are spinning up, it is because to access the user-share, and to give you a combined listing of the files on it, all the disks involved must be read UNLESS the directory nodes are in disk buffer cache memory.  (and therefore must spin up to read the directories)

 

The use of cache_dirs, a program I wrote long ago to attempt to keep the directory information in memory by repeatedly accessing it every few seconds should keep the disks from spinning up if it is just being scanned for directory listing information.

 

You cannot set spinup groups the way I am guessing you are, by user share, unless there is absolutely NO overlap of disks involved..

 

They can only be used for disks that affect each other at the physical disk-controller level.  In other words, if the disk controller stops and waits for a spin-up before doing anything else to a paired port, it belongs to a spin-up-group.

 

The reason you are having to wait till morning is to have the issue is that it takes that long for the disk-buffer-cache to  fill with more recently accessed disk blocks, replacing those previously accessed on the physical disks with the user-share directory shared on the SSD.  If those blocks of data were still present in the disk buffer cache, the cached directory information would not require the physical disks to spin up..

I understand everything you said up there and it makes sense.  The only thing I am not clear on is why this was less of a problem in 4.7 and RC-4, and more of a problem in RC-5?

 

Having said that, this morning it spun up all those drives and I am on RC4, but going on what you said that is probably because the last thing I had done last night was to reboot the sever so nothing had been cached yet.  This was the first access after reboot. 

 

Would RC4 keep the directory information longer than RC5?  It may sound crazy but I know RC4 and 4.7 was allowing me to access without needing to spin everything up and RC5 was was spinning them up every morning.  Based on this the only reason I can surmise is RC5 is dumping the cache overnight (or after a certain number of hours), and it took longer in those other versions. 

 

Does the program you wrote work in V5?  Is there any downside to using it?  Where do I find it?

I found the Cache_Dirs information and will give this a try. 

 

We're there any other changes from RC4 to RC5 that would reduce the length of time for the directory info to stay cached? 

I found the Cache_Dirs information and will give this a try. 

 

We're there any other changes from RC4 to RC5 that would reduce the length of time for the directory info to stay cached?

There have been different kernel versions, but all work the same, all cache disk blocks and re-use the least-recently-used disk buffer when new accesses occur.  It was probably just chance you noticed it more on some versions than others.

 

Your isolation of the SSD  on its own controller left spin-up-groups entirely out of the picture.  Noticing that all the disks were on the same user-share pointed it to be a cached directory issue.

 

Give cache_dirs a try.  It will work in all versions of unRAID.

There have been different kernel versions, but all work the same, all cache disk blocks and re-use the least-recently-used disk buffer when new accesses occur.  It was probably just chance you noticed it more on some versions than others.

 

Your isolation of the SSD  on its own controller left spin-up-groups entirely out of the picture.  Noticing that all the disks were on the same user-share pointed it to be a cached directory issue.

 

Give cache_dirs a try.  It will work in all versions of unRAID.

 

I have it installed now and back on RC5. 

 

When cache_dirs is running, if I copy of files will it automatically update the cache?

 

I'll report back tomorrow how it worked, and mark this resolved if all is well. 

 

I assume there is no reason to leave the SSD on a separate controller once cache_dirs is up and running?

 

All seems fine this morning and running RC 5.  Thanks for the help with this.