Re: Which Hardware for Firewall

[Joachim Schipper <j_(_dot_)_schipper_(_at_)_math_(_dot_)_uu_(_dot_)_nl>]

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