Re: Squid performance - SquidFS

On Fri, 28 Aug 1998, Stewart Forster wrote:

> > No FS you can name handles the way squid works really well, due its nature
> > of lots of objects coming *and going* all the time. Not even CNFS, since
> > we have objects being removed from all over the store, not in batches like
> > news does.
>
> Agreed.
>
> > So, using one big file (or going right to a partition) should be a much
> > better way to do things. This is how my patch works. You create 1 big file
> > to store all objects in. Each StoreEntry has a new member called "offset"
> > which is simply the byte offset for that object within the file. You want
> > to read the object? Seek to "offset" and read x bytes (more than 1 read is
> > generally required). And, removing an object from the store requires a
> > single write of 512 bytes (if we weren't worried about crash recovery, we
> > wouldn't even have to do this).
>
> Okay, this is generally how my design works. There is one big file
> per disk partition. There is a thread responsible for IO to that partition
> and it orders the reads and writes as required to optimise disk activity.
> Fragementation is not an issue for my design however since it assumes all
> writes/accesses are in multiple of 8K chunks, down to a minumum of 4K frags.
> With a 2:1 chunk/frag size ratio, fragmentation isn't an issue right until
> the disk practically is full. If we keep that last 1% free, we're happy.

I think I don't understand this chunk/frag method you keep refering to.
Care to outline it? Or point me somewhere? I can't picture any method that
doesn't lead to fragmentation.

/-----------------------------------------------------------------------/
/ Eric Stern - PacketStorm Technologies - (519) 837-0824 /
/ http://www.packetstorm.on.ca /
/ WebSpeed - a transparent web caching server - available now! /
/-----------------------------------------------------------------------/
Received on Tue Jul 29 2003 - 13:15:53 MDT