Re: [squid-users] COSS cache_dir size exceeds largest offset at maximum file size

On Mon, 7 Dec 2009 10:58:18 -0500, Jason Healy <jhealy_at_logn.net> wrote:
> On Dec 7, 2009, at 1:37 AM, Amos Jeffries wrote:
>
>> For some reason the safety check that is catching you uses > instead of
>> >=
>> I'm not sure why. If you want to experiment you could change it
manually
>> and rebuild. Around line 864 of src/fs/coss/store_dir_coss.c.
>
> It looks like I'm off by more than just a single unit:
>
> 2009/12/05 12:16:00| COSS largest file offset = 4194296 KB
> 2009/12/05 12:16:00| COSS cache_dir size = 134217728 KB
>
> The largest file I'm able to use is 4095 MB, instead of the 131072 MB
> requested. Am I smacking up against some architecture-specific
constant?

Yes, not sure what I was thinking yesterday. (multiplying by block size
twice, sheesh) The constant is inside Squid. Maximum of 2^25-1 files per
cache == "largest file offset".
  cache size < largest file offset * block size.

Plus the default 10 COSS in-memory stripes (10MB in your case AFAICT) are
counted as part of the total cache file space, but not mentioned in that
mini report.

>
> Possibly related: I'm just using the standard Debian build process, so
> maybe it isn't guessing everything correctly. I want a 32-bit build
with a
> maximum address size of 4GB and largefile support. Should I be
explicitly
> passing in something like:
>
> --with-build-environment=POSIX_V6_ILP32_OFFBIG
>

Should be automatic. If in doubt add it. COSS does need it.

Amos
Received on Mon Dec 07 2009 - 22:06:13 MST