Re: [squid-users] NOTICE: realloccg /cache1: file system full, again, Solaris 2.6

On Mon, Oct 12, 1998 at 05:38:11PM +0200, Javier Puche. CSIC RedIRIS wrote:

> I've been having the same problem reported by Chris Tilbury some time
> ago, the message at the console:
>
> NOTICE: realloccg /cache1: file system full
>
> but filesystems have plenty of space.
>
> Anyhow the filesystems were already newfs'ed with: (Solaris 2.6, squid
> 2-RELEASE)
>
> newfs -m 1 -c 16 -o time -r 7200 -C 8
>
> I have done it now with:
>
> newfs -m 1 -c 8 -i 1024 -o time -r 7200 -C 8
>
> but I am no really convinced that the problem is the number of
> cylinder groups as Chris noted.

I've just had my call with the answercentre closed now, and have some
answers. The problem is caused by fragmentation. UFS is just not well
equipped to handle the kind of filesystem workload (continuous
creation/deletion of many small files) that an application like squid
requires.

I have a couple of potential solutions and a "tip", none of which I have
tried yet and if anyone decides to test them first, then on your own heads
be it. :-)

First, the tip, is to set minfree to 1%. Because of the nature of the access
to these filesystems, I've been told that you won't see any performance drop
under 2.6 if you reduce this to 1%. This will free up a little more space,
although nothing of the order of magnitude that is being lost.

On to the fixes. Firstly, since the problem is a fragmentation issue,
reducing the blocksize on the filesystem should help. The default blocksize
is 8192 bytes, and this can be lowered to 4096. This will result in smaller
chunks of space being initially allocated for each file and will help to
reduce (but not remove) fragmentation.

The gotcha here is that if you're running on a Sun4u platform -- ie, any
kind of modern UltraSPARC system -- then this is likely not to work. The
minimum blocksize you can have is the same as the pagesize, which (according
to the manual page) means that 4096 bytes is not an option although Suns
internal answercentre documentation is, apparently, less clear on this
issue.

The second potential fix is to change the optimisation strategy of the
filesystem from "space" to "time". This alters the allocation strategy for
files and may result in more space being used. It may also have a
drastically bad effect on performance of the filesystem.

The third potential fix, which I've already mentioned here once before, is
to dig deep into your pockets and buy Veritas VxFS. VxFS supports online
defragmentation and is more intelligent about how it allocates space. Sun
were fairly confident that if nothing else worked, then this would.

I'm going to fiddle with minfree and the optimisation for space strategy on
one of the disks tonight, and see how things progress. Neither of these
require the filesystem to be remade.

Should anyone care enough to take this further with Sun, then apparently the
code that needs to be rewritten to cope with the demands squid places upon
the filesystem is in "ufsalloc.c".

Cheers,

Chris

-- 
Chris Tilbury, UNIX Systems Administrator, IT Services, University of Warwick
EMAIL: cudch+s@csv.warwick.ac.uk PHONE: +44 1203 523365(V)/+44 1203 523267(F)
                            URL: http://www.warwick.ac.uk/staff/Chris.Tilbury