I'm not sure if it's a new problem but it seems to be getting worse for me.  I'm using 4.2.1 on a MD-1500 and if I try to do a directory listing of a user share after the drives have spun down it appears to spin the drives up before returning the results (read - takes a long time with 8 drives in the system).  I was under the impression that the user shares were kept in Ram as symlinks to the actual files so something like a directory listing should be instantaneous, even when everything is spun down.  Is there some reason that it is looking to the physical disks to re-build the user shares (preferably something I could do to have it stop doing that)?

 

It wouldn't be so annoying but XBMC seems to have a timeout and it only populates with a partial listing and I actually have to go in and out several times before all of the movies show up.

 

I don't really need the writable user shares as I am adding capacity only when I run out and it's just video files that I rip manually so specifying the disk on write isn't a problem.  If 4.1 doesn't have the same "behavior" I can go back to just re-scanning the shares after I rip files until something can be done.

 

Actual performance once the disks are spun up is great, easily saturating my laptops 100Mbps connection.

I have seen this happen from time to time and it's on our bug list to investigate.

 

You are correct that user shares are kept in RAM, but the symlink does eventually point to an inode block of the actual file on disk.  If these inode blocks get kicked out of the cache, then next time you try to get a directory listing they get read back in again (and thus you may see the disk spin up).  Anyway I think this is what's happening & there are a few ways we can fix - but I need to confirm.

Is there anything I can help do to confirm or is it just something you have to do internally?  It happens every time the drives spin down so it's fairly easy for me to reproduce if you need me to enable some logging (didn't see anything obvious in the default level syslog).