Re: Squid-FS

--MimeMultipartBoundary
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alex Rousskov wrote:

> A better approach would be to write a high (Squid) level "Squid FS".
> Unfortunately(?), we do not have time for this in 1.2.

I am not convinced that a Squid-FS is the right path for Squid.

Pro:
* Flexibility
* Performance

Con:
* Complexibility
* Consistency
* Crash recovery

Flexibility can easily be gained ontop of a normal FS, using separate
index files if performance is important, embedding into the "real" files
if consistency is more important.

Is the FS overhead really that huge that it is worth the amount of work
needed to build a Squid-FS?

The average FS already have strong structural consistency management
built in, and well tested recovery tools when things do fail.
Transaction based filesystems is available that can handle powerlosses
and other "crashes" without extended downtime (fsck). A Squid-FS is much
more sensitible to both hard (power, hardware) and soft (segfault, out
of memory) crashes.

I think that the time needed to build a reliable and efficient Squid-FS
is much better spent by improving, cleaning and specifying/defining the
core functionality in Squid. There is other people making a living in
selling high performance filesystems/storage if needed.

/Henrik

--MimeMultipartBoundary--
Received on Tue Jul 29 2003 - 13:15:47 MDT