Re: HUGE size of squid binary after compile

John Line (as web server manager) wrote:

> Ah, I misunderstood - thought you were saying that df actually displayed the
> number of fragments. I hadn't heard about the problem you describe here, but
> if true I suppose it could be described as both "reasonable" (it is the
> amount of free space, after all) and "misleading" (since it is not
> necessarily all usable).

I don't have access to a Solaris 2.6 system at the moment, but
2.5 df certainly reports free space as the sum of blocks+fragments.

> fragment. For something like squid with *very* busy log files, I'd imagine

You aren't keeping your log files on the cache disks are you? If you are
then you should defenitely look into moving them to separate disk(s)
both form performance and reliability reasons.

Squid can cope gracefully with a cache disk that fills up, but not if
it can't write to a log. This applies both to the normal logs, and the
metadata log files.

> that growing another 512 or 1024 bytes happens *very* frequently. And since
> (if Solaris 2's ufs implementation matches that described in the ("The")
> 4.3BSD book) the fragment used at the end of a file when it is first written
> will always be best-match even with optimisation for time, it should only be
> files that are extended subsequently (e.g. logs) that actually risk
> using/wasting full blocks - and that's likely to be a very small number of
> files.

Well.. check what the fragmenation levels are on your disks (reported
by fsck). If it is low then your system behaves nicely.

> I can believe it may hit problems in spite of that, but wonder if it may
> (for example) happen primarily or only with the 2.6FCS bug that results in
> the effective free space reserve being zero, which might well make a mess of
> the decision about when to switch optimisation mode.

Not to unlikely. Most of the reports seen on this issue has been
Solaris 2.6 systems.

---
Henrik Nordstrom
Spare time Squid hacker