unRAID Server release 4.5-beta12 available

[Joe L.]

The spinup occurs when just reading the directory tree. The SMB client is not requesting anything funny, but just the directory listing. So it can't be an SMB client problem. (And yes, I do have JoeL's cache script running.)

I can think of four possibilities here, but there could be more.

 

1. You are using an older version of cache_dirs.   It was only in the last version or two that the -noleaf option was added to the "find" command.  (It took a while for feedback from users to identify the best way to scan an entire directory tree to gran the inode data used when requesting a directory listing via SAMBA)

The current version is 1.6.4.  You can verify the version you are running by typing:

cache_dirs -V

2. You are actively using the server, either clearing disks, or playing and/or storing files.  (Since the disk buffer cache is shared among all processes, and it operates by freeing the least-recently-accessed blocks when asked to use a new block of the buffer when accessing a disk.  If the other accesses of disk data use the buffer cache more quickly than the loop cycle time in the cache_dirs program, then eventually a disk will need to be accessed since the directory inode data is no longer in the cache when the listing is requested.)   If you've set the minimum loop cycle time to something other than the default of 1 second, it might be too long between scans.

3.  You have less memory than needed to cache all the directory information used by your files.  (In other words, you have a very large media collection, and they all don't fit in the amount of memory available on your server)    I MUST exclude my "data" directory.  It has over 84,000 files and if all the disks are spun-down it takes over 4 minutes to do a directory scan.  I only have 512 Meg of ram, so it displaces the listings I usually cache using "cache_dirs" from the cache.

 

4. Unbeknown to you, your SMB client is accessing data other than the directory listing (names of the files and folders) when it is displaying the collection of media to you.   For example: If it is displaying the cover-art graphics, then that data will not be in the cache and the drives will spin up.)

I'm not sure if unRAID can possibly know which disks need to be spun up and which don't. I don't know enough about the unRAID driver internals to answer that.

About the best it can do is spin up the set of disks we organized as a "user-share" as a single set whenever one of the set is accessed... but all in parallel, so we wait 10 seconds or so ... vs. over a minute if spun up in series.   Each user-share is accessed through the "shfs" file-system driver.  It knows which physical disks make up the set for a given user-share.  It could, if an option for it was provided, issue individual "spin up" commands in parallel for the group when one is accessed.    Some would not want this behavior,so if it existed, it would have to be something we could enable or disable on a per-user-share basis.  If we had something like this the very first access of my "movies" share to get its directory listing would spin up the affiliated disks holding the data.  (and the listing would return almost immediately because cache_dirs had the directory data itself)  When I press "play" on my media player, it would play with no extra delay, since by then the disk would be spinning.

  But I can say that this "chained" spinup is the biggest (and only?) problem I have with unRAID. So I hope that some day there will be a reliably working solution for that...

Me too.  When I finally hit "play" on a selected movie title  the time needed to spin-up a disks causes my media player to think the share is not available, and I'm forced to re-select the server, re-traverse to the directory, and re-select the movie.  We've gotten used to it, but it is sure annoying.  It had the directory listings in cache, so it can list them quickly, and if the feature was added so it would spun up the disks affiliated with that share once it saw me listing it, the disks would be spinning by the time I press play and I would have nothing between me and my enjoyment of the movie.

 

In the interim, until lime-technology is able to get around to this, I'm going to explore using inotifywait on the /mnt/user shares.  If one is accessed in any way, I'm going to try to script the spin up of the affiliated physical disks.   I can see in my syslog that the spin-up commands can be issued in quick succession, so I think it might work.   I have an older script that did something similar, but it used "wget" on the spin up button on the management interface and not the newly available spinup commands.

 

Joe L.

[flixxx]

Hi,

 

one thing I noticed with the new beta (After 11) is that the parity disk does not spin down anymore. Is this expected behaviour?

[Joe L.]

Hi,

 

one thing I noticed with the new beta (After 11) is that the parity disk does not spin down anymore. Is this expected behaviour?

The parity drive does spin-down for me. (on beta13)

[madshi]

I can think of four possibilities here, but there could be more.

 

[...]

 

Thanks, Joe, I'll give that a try...

[flixxx]

Previouis post about parity not going to sleep... ID 10 T issue.

 

FOUND THE ISSUE, Sorry, nothing wrong with unraid.

 

[duderaid]

SAS still not working properly.  Ok I have a  LSI SAS3081E-R see this post:  http://lime-technology.com/forum/index.php?topic=3109.0

 

The drive is recognized in by linux and unraid sees it.  The problem is when I assign it to a disk in unraid and start the array it doesn't show up.  The error that comes up is

 

"Dec  2 17:25:03 Backup kernel: md: import disk4: HDIO_GET_IDENTITY ioctl error: -22"

 

I think it's still a bug with the driver but can't find any info on what the error -22 is.  I've sent Tom an email with my syslog for his review.  Anyone else have any ideas?

 

Thanks

 

Erik

 

 

 

 

I have seen this too with a 3ware. Apparently  HDIO_GET_IDENTITY isn't supported on SATA or SCSI.  see my post here

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