Re: HUGE size of squid binary after compile

John Line (as web server manager) wrote:

> Are you sure about that ...? I've never seen Solaris 2 report fragments (the
> only thing I recall reporting fragments is fsck...), though by default space
> is reported in 512-byte blocks rather than KB (seems to be a SysV versus BSD
> distinction) - "df -k" will get KB. The free space percentages should be OK
> though, giving percent of non-reserved space free.

I have been told that Solaris 2.6 df reports free diskspace as the sum
of
free fragments presented as 512-byte blocks or KB depending on which
options you use.

The problem is then that the filesystem uses blocks of 4KB or 8KB
divided
into fragments, and only the last portion of a file may be located in a
block fragment. If your filesystem allocation policy is "optimize for
time" and you have lots of small files then you may end up in a
situation
where you have lots of free fragments, but no really free filesystem
blocks. It is then impossible to store files requiring a full filesystem
block or more (or is the limit is one fragment?).

If you change allocation policy to "optimize for space" then the last
portion of a file is always located in a fragment, and the filesystem
tries to maintain as many free blocks as possible. If the policy is
"optimize for time" then it never uses fragments of a partially used
block if there is a free block available.

For a Squid cache disk "optimize for space" is suitable, since the
files are written once using larger (8KB) chunks, and then stays at
the same size.

For most other applications "optimize for time" is more suitable.

---
Henrik Nordstrom
Spare time Squid hacker