Re: Squid-FS

--MimeMultipartBoundary
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

On 21 Apr 98, at 15:07, Alex Rousskov <rousskov@nlanr.net> wrote:

> On Tue, 21 Apr 1998, Henrik Nordstrom 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.
>
> If you go back to the previous posts on this topic, you will see that by
> SquidFS I mean "big", "DB-style" files with many objects per file _on top_ of
> an existing FS. Thus, we gain performance benefits (see previous posts for a
> long list) and preserve advantages of Unix FS (recovery and such).

 Anything ontop of existing FS means indepth knowledge and respect of that FS'
 performance paramteters, influencing variables, etc anyway.
 What I want to point out is that it is unavoidable to tune squid's behaviour
 to correspond to most efficient disk-io access-pattern whether squid has its
 own FS ontop of OS'es or uses plain OS FS.
  
> > Is the FS overhead really that huge that it is worth the amount of work
> > needed to build a Squid-FS?
>
> Is reducing hit response time by half "huge"?

 I believe there is lots of ways to reduce it without special FS.
 
 So, basically I agree with Henrik that squid-FS should be held back for awhile.

 ----------------------------------------------------------------------
  Andres Kroonmaa mail: andre@online.ee
  Network Manager
  Organization: MicroLink Online Tel: 6308 909
  Tallinn, Sakala 19 Pho: +372 6308 909
  Estonia, EE0001 http://www.online.ee Fax: +372 6308 901
 ----------------------------------------------------------------------

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