I've been thinking about the new cache drive feature and usage.

 

I think it's a great idea, but also can be expanded upon.

 

I know that the mover script can be adjusted to allow the end user to filter out what they may not want moved.

 

I was wondering if it were possible or worthwhile to adjust the caching feature to use a specific directory instead of the whole root of the drive.

 

I.E. Instead of building the cached shares off / on the cache drive, build them within a directory tree such as /var/cache.

 

My reason is that the drive itself could be used for other features/uses.

 

In particular I would like to use it as a full slackware development environment without having to adjust the mover.

 

In addition I would like to set up a tree which gets mounted on top of root's /usr/local so that I can install packages statically.

 

This leaves root in ram during normal operations, with /usr/local mounted via mount -o bind to a directory tree on the cache drive and allows us to reboot using the cache drive as a development/hybrid environment.

 

So if the standard cache directory were /var/cache on the cache drive, all functions above can co-exist with minimal change to the mover.

 

Although I believe there might be a number of changes in the FUSE/User share environment.

 

Thoughts?

 

I really agree.

In fact the whole cache disk thing is a good excuse to have an extra disk doing other things.

 

And it won't be a problem for Tom.

 

Just that the whole "real" cache tree will be one directory deeper (you can use a single letter directory name to minimize impact on long paths)...

 

/c for example

 

 

It would really help me, especially in the Chenbro ES34069 Mini-ITX Home Server/NAS Chassis

http://www.logicsupply.com/products/es34069

 

I have a small 2.5" drive in there as a slackware development system.

So if I could have this double duty, it would help out a great deal.

 

I know, I know, it's a small case.. LOL.. I wanted it that way.

It's got a mobile core 2 duo and I was basically building a machine to replace my Thecus 5200...(yet cannot quite do that until NFS is available.)

 

 

 

 

 

 

 

 

I was wondering if in the future we could use the cache drive as a place to store metadata for our media files so that only that one drive need be spun up when being accessed via frontends on other PCs.

 

It would also be handy as storage space for virtual machine images if needed to handle a lightweight database/querying engine.

At this point the only reason I would consider installing a cache drive is for a swap file. We could probably do that ourselves though it would be nice if the drive was there to automatically create one for the less linux savy users.

All good points here.

My only wish was that the cached files were put in a directory as in /var/cache/shfs or /var/cache/unraid and the rest of the file system was left intact and untouched.

 

if this were the case, you could have anything in the root filesystem as long as it doesn't touch the unraid cache directory.

Anything being, a full slackware distro, a swap file, or whatever.

 

As far as a swapfile on the cache drive, that can be done easily with a hidden file and a startup script.

 

The only issue I've been seeing is that we need events triggered after emhttp mounts all the disks.

We can easily modify our go scripts, but we need some sort of semaphore or event posted when emhttp believes the environment is ready for secondary level installs.

I was wondering if in the future we could use the cache drive as a place to store metadata for our media files so that only that one drive need be spun up when being accessed via frontends on other PCs.

 

It would also be handy as storage space for virtual machine images if needed to handle a lightweight database/querying engine.

 

Great idea. Then, when browsing my 500+ movies in thumbnail mode, there'd be no delay as the disks spin up.