Re: everything is a file ..

On 17 Oct 2000, at 0:15, Adrian Chadd <adrian@creative.net.au> wrote:

> On Mon, Oct 16, 2000, Andres Kroonmaa wrote:
> > On 14 Oct 2000, at 12:07, Adrian Chadd <adrian@creative.net.au> wrote:
> >
> > > ok, whilst hacking at some more ideas, I still want some clarification
> > > as to why having everything as a file is a bad idea. I would like
> > > some people to dump to me why it is bad to have every StoreEntry require
> > > a backing squidfs file, because I'd like to see how many of them I
> > > could "optimise out" with some ideas.
> >
> > what do you exactly mean? a separate backing file for each StoreEntry?
> >
> > > (yes, I can think of a whole slur of reasons why its bad, but I can
> > > then think of a whole slur of ways to make them go away .. :-)
>
> Like in squid-1.x , even temporary files are allocated a disk file.
> After doing some evaluation of the code for modio v2 + further commloops
> code, I've realised that squid-NOVM would actually be the best choice.
> (which is actually kinda scary. :-)

 OK, you are talking about creating FS file as soon as StoreEntry is created
 vs. creating FS file only when and if swapout starts?

 btw, if I recall it right, then squid 2.x is NOVM type, isn't it?

 both VM and NOVM had their problems. VM buffered whole object in ram before
 swapout, overloading memory, NOVM created FS file way too soon, and couldn't
 skip creation of FS file for noncacheable objects, potentially overloading
 FS without any good. Perfect solution imho is somewhere inbetween.
 Fixed-size FS buffer should be required to be filled before FS file creation
 is considered. In most cases at this time object cachability is known, and
 with decent buffer most object sizes will be covered, meaning that swapout
 can happen in one shot (atomic "open+write+close" if you like). This is
 good for longwaited FIFOFS, and allows us to pick FS based on object sizes,
 ACL's, etc. It is also good for any FS type, actually.
 If we require FS file creation as soon as StoreEntry creation, I'm afraid
 we are pressing too much load on FS meta which could prove often wasteful.

------------------------------------
 Andres Kroonmaa <andre@online.ee>
 Delfi Online
 Tel: 6501 731, Fax: 6501 708
 Pärnu mnt. 158, Tallinn,
 11317 Estonia
Received on Mon Oct 16 2000 - 10:55:42 MDT