Upgrading and Squid data / logdirs
-
Hi,
I'm running pfSense with /var and /tmp as ramdisks.
The system does have a local SSD drive, which is where pfSense is installed and also the squid cache should reside.
I've changed the paths for the cache and logs as follows:/data/squid/cache (20GB cache, rest is not used)
/data/squid/logs (only on till we know ICP works well)I wonder if this is is going to survive an upgrade though.
Basically losing the whole 20GB cache is less of a big deal, as long as it's at least re-created.Do you happen to know if that just works?
-
The settings, yes… the data - depends on which package version you have currently installed - there's "Keep Setting/Data" checkbox since 0.3.8 to preserve logs and cache across upgrades. Not exactly sure what's the big deal here beyond the fact that from 0.3.8 on, the package refuses to manage any locations outside of /var/squid/ on purpose (will not delete the cache/log dirs regardless of the 'Keep Settings/Data' checkbox state above, will not clean the cache either). You'd better remount your SSD things under where are they supposed to be.
-
So, in practice that means I'd need to turn off the ramdisk mode.
Or, try improve the package, or change the ramdisk script to put in a symlink.
Since updates aren't too common and it's a cluster the cache efficiency wouldn't drop too much if we lose one of the caches./var on the ssd too is just a way to make it burn out faster, I'd love it to perform well for ~5 years which is stretching it quite a bit.
Oh, and I have the 0.3.8 version. it allowed the change.
-
Not really sure what "burn out" are you talking about. These days, the SSDs will handle hundreds of TiB of writes. If you want the thing managed by the package, simply mount things under /var/squid. You can still change it to whatever, just don't expect those dirs it to be maintained by the package (you'll get self-explanatory log warnings about that.) One accident with recursively changing permissions on / has been just enough.