Re: Raw vs. cooked file systems for cache?

Eric Stern wrote:

> Cisco cacheengine reportedly uses a cyclic filesystem, which is a VERY
> attractive design except that I imagine it is disasterous to your hit
> rate.

Well, you could probably write back those few objects that should not be
wasted without a to high impact on I/O usage. Writing in a cyclic
filesystem is close to free provided that you make proper use of
buffering, and sequential reads are not bad if planned. This is as long
as the cache is big enougth that (real) LRU age is close to the cache
cycle.

This write back can also be piggy backed from cache hit processing to
limit (or even eleminate) the number of freshly referenced objects that
are at the tail. A reasonable rule is to write back the object at the
head if it is more than 50% back in the file system (shoule be
configurable).

A cyclic filesystem is also very interesting from a recovery
perspective. It is very easy to maintain stable checkpoints, making
cache recovery close to instaneous even after power failures.

It is also interesting from a RAID perspective. It may be possible to
use RAID 5 with a negligible performance impact, as long as the writes
are done in chunks big enought to fill the RAID 5 stripe before it is
commited. This allows one to build a high-performance fault-tolerant
cache box.

The next idea popping up in my mind is using a chunked cyclic filesystem
with static index logs (once the index of one chunk is written, then is
is not rewritten until the chunk is reused). This simplifies things a
lot.

Using a cyclic filesystem will waste some diskspace, but not terribly
much. Maybe in the range of 15%.

Hmm.. I may change my opinion on the Squid filesystem issue... ;-)

---
Henrik Nordstrom
Spare time Squid hacker