In article <Pine.LNX.3.95.990505232521.28455A-200000@squall.mgl.ca> you write:
>The README is attached. The code is available at ftp.packetstorm.on.ca in
>/pub. The filename is squid-coss-<date>.tar.gz.
>
>Please read the README before you go and download it.
I tried it on FreeBSD 3.1 and it works after making the small
Makefile.in change I already sent you last week.
>This code *should* be stable enough to run benchmarks on. I'm hoping
>someone will do so. I'll be embarking on that myself in the next few days.
Do you have any results yet? I was only able to do some normal browsing
test on my non-networked slow PC at home and that's not the ideal setup
for doing benchmarks.
>Hope I'm not stepping on any toes here, but there doesn't seem to be much
>progress on the "official" squidfs, and I'm rather anxious to see squid
>get better performance. The bakeoff results were somewhat disappointing.
What's the general idea on SquidFS? Make a general SquidFS API first
such that multiple approaches can be tried and compared easily? The INN
news server has a so-called storage API which permits such things.
>The included code is ONLY the /src directory from the squid 2.2-STABLE2
>source tree. Do not untar this code into a source tree you really want to
>keep. I suggest you untar the squid 2.2-STABLE2 tarball, move it to a new
>directory (squid-2.2-coss or somesuch) and then untar this file into the
>/src directory of that tree.
If possible make a normal patch file (context or unified format) available
because that makes trying it out a little easier.
>Included is coss.conf. This is a good place to start as some of the
I could not find this coss.conf file anywhere...
>options are different than normal squid. You'll probably want to change
>cache_dir. Run squid with "./squid -f coss.conf"
>
>Each cache_dir (misnomer now) is either a single large file on a
>filesystem, or a disk partition. Even a raw disk device if you really
>wanted to.
I tried a large file, a /dev/sd device and a /dev/rsd device. The first
two work OK, the latter one (raw disk device) only seems to accept reads
and writes with sizes 2^X (X>=9).
>Known bugs, caveats and things to note
>--------------------------------------
>- I really took a hatchet to the source tree. many files modified with
> little or no comments or #ifdefs. once everything is working I'll make
> a patch against the main source tree. until then i'll maintain my own
> source tree.
It would indeed be nice to have a #ifdef COSS everywhere and a configure
option --enable-coss.
>- cache_dir specifies size in BYTES
In cache.log these size are still reported in Kbytes.
>- not tested with async-io yet! I wanted to get the COSS mechanisms
> working before I ventured into that territory. If you feel adventurous,
> give it a try. Patches gratefully accepted.
I want to try FreeBSD's native aio_read and aio_write implementation
(POSIX 1003.1B AIO/LIO facility) when time permits.
Arjan
Received on Tue Jul 29 2003 - 13:15:58 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:08 MST