On Mon, Aug 20, 2001, Chemolli Francesco (USI) wrote:
> > in a ufs-style FS, the data may come back in chunks since the object
> > is big, but if the object is a small image it'll come back
> > in one chunk.
>
> Ok. I second this then.
> It would be best if there was some kind of pressure on the chunk size:
> when RAM becomes scarce decrease the chunking. If we go out of core
> performance is going to be horrible anyways.
My aim is to have a NOVM type squid with COSS - I can always modify the
OS idea of caching, and possbly add some "hinting" in Linux/FreeBSD
for performance.
> > There's some magic with the SM_PAGE_SIZE size in the code, and there
> > was even before I got to it. the CLIENT_MEM_SOCK_BUF is also 4096
> > bytes and when I tried upping it a while back things fell over.
>
> We can keep it as a basic block, shouldn't be a problem to temporarily waste
> a few k's.
Right. Well, I'm going to kill that very soon. The code shouldn't rely
on it being 4096 bytes. :-)
> Worse than that. I'm using the sourceforge ntlm-tag (which is better than
> what I'm running now in production, a 2.4-DEVEL3-NTLM-worse-than-hell).
> Unfortunately it can't be avoided. I _HAVE_TO_ properly implement NTLM
> authentication NOW.
> On the plus side, Aug 10 ntlm branch has faitfully served over 5.5 million
> hits
> over 10 days (before crashing, but I try not to think to that).
*laugh* WHat did it crash on? :)
> > This is really starting to irk me somewhat. I'd suggest
> > either creating
> > a 2.5 branch for you guys to keep doing NTLM stuff on, or force you
> > two to MFC the NTLM and auth code back to squid-2.4.
>
> No way to do that. Auth-changes are way to wide.
Ok. Perhaps we should branch off squid-2.5 soon?
> > I note that more and more people on squid-users are using squid-2.5
> > in production, and its rather scary for the developers. Well, at
> > least me. :-)
>
> It is scary, and I am scared (but somewhat happy because this means that we
> get more meaningful bugreports) :)
> Maybe it really is time to freeze 2.5 and short-schedule COSS and aio and
> similar for a 2.6 to follow 2.5 by a couple of months?
The question is getting 2.4 and 2.5 out the door. I still think we
should just tag stable2 with how the squid-2.4 branch looks now.
I then think we should just branch 2.5. Its messy, but I don't see
any other option. I think 2.5 has the options in it that we targeted
a while back on the squid-dev list.
Ok. Here's my vote:
* tag squid-2.4stable2
* branch the squid-2.5 branch
* tag squid-2.5devel1
Once 2.5 has been tested a little more widely we can stuff squid24 into
maintanence mode and concentrate on making 2.5 rock solid, whilst working
on new features for 2.6 .
Any other votes? Duane, Henrik, Robert?
Adrian
Received on Mon Aug 20 2001 - 22:08:30 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:14:13 MST