Thanks Henrik/Marc
My recommendation is going to be that any implemenation of async i/o is
delayed and incorporated into a general upgrade of Squid to the latest
stable release.
Regards
Jeff
-- Jeff Richards Technical Consultant Unix Enterprise Services jeff.richards@centrelink.gov.au Tel: +61 2 6219 8125 Henrik Nordstrom <hno@squid-cache. To: jeff.richards@centrelink.gov.au org> cc: Marc Elsen <marc.elsen@imec.be>, <squid-users@squid-cache.org> Subject: Re: [squid-users] async i/o 06/11/2003 09:04 |---------------------| | ( ) Urgent(4 hours) | | (*) Normal(24-48) | | ( ) Low(72 hours) | |---------------------| Expires on On Thu, 6 Nov 2003 jeff.richards@centrelink.gov.au wrote: > So there is no definitive "yes, it's stable in version X"? It has been considered stable by the devopers since Squid-2.2 something. There is at this time no known bugs in the aufs implementation of Squid-2.5.STABLE4, and very many uses aufs in very high load situations with great success. Due to the nature of history accumulating over time there is known bugs in all earlier Squid releases, both in aufs and other aspects of Squid. It is also true that there has been reports about problems with aufs and/or conntrack in RedHat Linux indicating a memory leak somewhere in the kernel, but I can verify that I have not seen any such problems using standard Linux kernels. The only common dominator I have seen in these bug reports is that they use RedHat linux kernels, transparent proxying and aufs. What can be noted is that aufs has not been very much tested on Linux versions using NPTL threading library (RedHat 9 or Linux-2.6). Regards Henrik Important: This e-mail is intended for the use of the addressee and may contain information that is confidential, commercially valuable or subject to legal or parliamentary privilege. If you are not the intended recipient you are notified that any review, re-transmission, disclosure, use or dissemination of this communication is strictly prohibited by several Commonwealth Acts of Parliament. If you have received this communication in error please notify the sender immediately and delete all copies of this transmission together with any attachments.Received on Wed Nov 05 2003 - 15:10:49 MST
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 17:21:09 MST