Re: [squid-users] wrong diskspace count and assertion failed: diskd/store_dir_diskd.c:1930: "buf"

On Saturday 14 January 2006 19:13, Henrik Nordstrom wrote:
> On Sat, 14 Jan 2006, H wrote:
> > i don't know since the assertion failure ocurres independent of q1/q2
> > values
>
> Not the assertion in the subject. It's only if there is too many scheduled
> diskd I/O requests at the same time, and these are limited by the q1/q2
> values.
>
> > after some time this function returns a bad buf value but why?
>
> The assertion says there is no I/O buffers left of the 96 statically
> allocated buffers per diskd.
>

let's see if I understand what you say here, you say that if either q1 or q2
is set to a high enough value to use all 96 buffers the assertion failes
and otherwise the msgs ar hold when reaching the q1 or q2 value and assertion
do not fail?

anyway I am surprised by your answer

certainly the received error msg do not say that in any way

probably you know that it means that

so the surprise is that you let us crisscrossing options for two month until
coming over with this wisdome

even so, I mean even if the error msg really is saying what you tell us here I
can not accept that squid ***crashes*** then for that and empties the cache
dirs then

If this error really means no buffers left then diskd processess should crash
also and ever when the msgs are busy - but in this case squid gets it right
and fails only for this particular transaction and can go on with diskIO soon
the msgqueues are free

Makes no sense to me that for buffers beeing out the diskspace count goes
wrong but if so it is really necessary to check and repair this particular
thing and for me this is a very serious bug

since this happens independent of usage, means it happens on low traffic
(<1000Kbit/s) and heavier (2-4MB/s) and also on heavy servers with 15-20MB/s
after a certain time and not under a certain charge I like to discard "buffer
out" - for me here is a leak somewhere which cause the problem, temporary
buffer out I can no state on my system when monitoring this particular event.

Obvious I should have more request on a heavy server so the problem should
happen here more but it does not. So if your answer is it then I should get
some relevant numbers with ipcs -o|a but the system is clear. Or is there
something else?

-- 
H.
A mensagem foi scaneada pelo sistema de e-mail e pode ser considerada segura.
Service fornecido pelo Datacenter Matik  https://datacenter.matik.com.br