On Mon, Apr 10, 2006 at 03:55:44PM +0100, Stuart Henderson wrote: > Joachim Schipper wrote: > > Falk Huseman wrote: > > You might also want to take a look at the 'async' mount option. Horrible > > filesystem damage is just around the corner, but it's not like that > > matters all that much for Squid's cache. Just be sure to properly catch > > unclean shutdowns. > > ...they can probably be brought back up after a crash much more > quickly with newfs than fsck :) Don't forget noatime too.
That's what I meant by proper handling... Also, since the on-disk stuff is quite possibly badly corrupted, newfs actually has advantages over fsck. Just don't do it on a clean shutdown, as it does slow down the proxy for quite a while. Hadn't thought of noatime, though, good pointer. However, while reading the following part (which was originally above the part I just quoted), I figured out a truly nasty optimization: > > > I thought about buying 2GB+ of RAM and running parts of the system > > > from RAM (tmp, squid-cache). Is this possible on OpenBSD? A quick > > > google search did not turn up anything. > > > > mount_mfs(8) could be helpful here. > > For squid: you could just turn off the disk cache and just use cache_mem... > http://www.squid-cache.org/mail-archive/squid-users/200409/0292.html It might be possible to use a combination; mount_mfs a disk, say /var/squid-cache-mfs, and then use rsync or somesuch to copy it to a regular hard disk (say /var/squid-cache). If rsync is properly configured, this should not detract much from performance, and still give you a properly mounted hard disk to get some caching up quickly after a crash. (cp -R or mount_mfs -P are both useful here.) Doing something like this inside Squid might be worthwhile, too - in fact, I'd not be surprised if someone has had this idea already. Joachim
