I like cache dir, but it would be nice to be able to cache ALL my directories such-that only the cache drive need be spinning (which it always is) to do a directory listing.  As it stands, I have to forego caching my TV segment due to RAM constraints.  Since a cache drive is likely to be spun up 24/7, it seems like a good candidate for shouldering some of the burden.

It's been discussed before, but not implemented because it would require a complete revamp of the cachedirs concept, not just an extension. Perhaps you could accomplish the same thing with a swapfile on the cache drive to ease the memory pressure? Or maybe not, I'm not sure if cached directory entries would be high priority enough to keep in memory and be swapped out.

 

Somebody with much more kernel memory management experience than I would need to weigh in on what is needed.

Another point that has not been bought up is that it would almost certainly be MUCH slower due to the overhead of having to read the cache disk to find the relevant information instead of simply pulling it from RAM.  This seems to me to be the equivalent of taking a system that uses SSD for its system disk and replacing it with a HDD and expecting a performance boost.

 

Since unRAID is 64-bit and thus all available space can be used for caching it seems easier just to buy an extra GB or so of RAM to achieve this and that requires no change to existing functionality.

Since unRAID 6 is 64-bit and thus all available space can be used for caching it seems easier just to buy an extra GB or so of RAM to achieve this and that requires no change to existing functionality.

 

This is the most cost effective way of doing it at the current time.

The man hours involved in some sort of kernel to disk based cache of dentry/inode tables is not trivial.

Then there is the ongoing maintenance.

 

Maybe one day LT will introduce caching at the usershare level.

Some sort of intermediary cache which grows and is stored.

However that would mean usershare access would be slower now. 

 

Dropping in large amounts of ram may satisfy the need easier, better and sooner then caching it via software changes.

I don't think the situation is as disadvantaged as you portray.

 

Would the approach be slower than RAM, SURE, but from my perspective it requires zero additional hardware.  (No additional ECC RAM required)

 

And it would CERTAINLY be faster than spinning up 15 sleeping disks.

 

Both= a plus from the user's viewpoint, keeping in mind; I'm not familiar with any horrendous code changes it would require.  I just thought it would be a step in a good direction.

 

 

Most folks aren't familiar with how the cache_dirs script actually works.  It is essentially doing the same thing that happens when you browse through the directory structure manually, but it's doing it automatically, for all directories you have, and on a regular interval.  This is a hack to essentially force the directory entries to stay in RAM, making it faster to retrieve when needed.  I've spent a great deal of time talking to Tom to see if there is a better way to accomplish the same end result, but the bottom line is that there isn't.  Doing this on a cache disk is just another complication on top of an already complicated concept.  I don't see this happening, but maybe at some point in the future if things change in the upstream.

The best workaround to accomplish what you want will be to create a swap area on a device you that you don't mind being used for this purpose (or a swap file).

The best workaround to accomplish what you want will be to create a swap area on a device you that you don't mind being used for this purpose (or a swap file).

 

Ummmmm....yeah.  I don't understand any of what you just said.

 

I was (ignorantly?) hoping there was some way to possibly cache the directory listing as part of spinning the drive(s) down.

 

Anyways, I just wanted to plant a possible seed for a future feature.  If the opportunity ever presents itself, I think it'd be a good idea and would lessen drive wear overall.  Thanks for listening.