Re: New: squid-1.2-SQUIDFS

From: James H. Cloos Jr. <cloos@dont-contact.us>
Date: 20 May 1998 01:50:49 -0500

>>>>> "Eric" == Eric Stern <estern@packetstorm.on.ca> writes:

Eric> ... I've changed the way Eric> squid stores files. ...

Eric> ----

Eric> Notes for squid-1.2-SQUIDFS

Eric> Instead of storing each object in a seperate file on the
Eric> filesystem, all objects are packed together into one file.

Cool. A feature squid, IMO, needs. INN's CNFS provides an enormous
speedup, by all accounts. Squid should benefit as well.

Eric> Some notes: - in squid.conf you specify the cache_dir(s) with
Eric> this syntax:

Eric> cache_dir <swap file name> <log file name> <size>

Eric> ie cache_dir /squid/cache/swap1.data /squid/cache/swap1.log 100
Eric> would configure a 100 megabyte swap file called
Eric> /squid/cache/swap1.data

'Twould be nice were a <size> of 0 to specify that squid should
stat(2) the file and use the st_size to determine the size of the swap
file. (Or if the swap file is a device, the appropriate IOCTL --
BLKGETSIZE in Linux for a block special -- should be used.)

Eric> space in the swap file is allocated in 1000 byte increments.

Why 1000 rather than, say 1024? :)

Since you're essentially writing a custom filesystem, you might want
to look into making it log-structured. Perhaps a simple fsck as well.
Certainly it is OK to just have to get the data from the src should a
disk crash, but killing the entire cache because of a squid crash is
less appealing.

Although 32-bit systems would be limited to a single file of not more
than 2G, an option to mmap(2) the swap files would be a performance
win. (Hmm, an Alpha or UltraSparc, FC/AL controller, couple of dozen
18G Cheetahs, devfs, a driver to expose each disk (not just partition)
as an mmap(2)able character special file, full HTTP/1.1 compliance....
Now *that* is a cache box!)

I hope all these ideas/comments do not come off as overwhelming. I'd
certainly volunteer to help. (As you might guess, I've been thinking
along these lines as well....)

-JimC

-- 
James H. Cloos, Jr.
<cloos@jhcloos.com>
Received on Tue May 19 1998 - 23:53:03 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:40:15 MST