Re: Squid fatal error

On Wed, Aug 02, 2000 at 10:03:11AM -0500, Jason Wang wrote:
> 2000/08/02 09:35:43| diskHandleWrite: FD 15: disk write error:
> (28) No space left on device
[snip]
> (df -k)
> Filesystem kbytes used avail capacity Mounted on
> /dev/dsk/c0t1d0s6 12913702 10164500 2620065 80% /cache1
> /dev/dsk/c0t0d0s6 8820137 6355290 2376646 73% /cache2
>
> (df -i)
> Filesystem iused ifree %iused Mounted on
> /dev/dsk/c0t1d0s6 1377607 11714105 11% /cache1
> /dev/dsk/c0t0d0s6 1037844 7922988 12% /cache2
 
This is on Solaris, I take it? If so, it sounds exactly like the problem
we hit a couple of weeks ago as a newly installed machine filled its cache
disk. I still don't fully understand it, but it appears to be down to a
"feature" of the Solaris filesystem, by which multiple file fragments
(default minimum size of 1k) may be written within a single disk block
(default size 8k on sun4u). No doubt there was good reason for it back in
the days of small disks, but it's not overly useful nowadays and
filesystems such as ext2 don't bother. The failure mode is certainly
unfriendly - we got no advance warning.

The symptom as above - df etc may show plenty of space free on a disk, but
if it's all inside fragented blocks, you can't write any large files, even
as root, though you'll likely be able to write some 1k files.

My solution: look at the newfs man page:

               -f fragsize
                         The smallest amount of disk space in
                         bytes to allocate to a file. The values
                         must be a power of two selected from the
                         range 512 to the logical block size. If
                         logical block size is 4096, legal values
                         are 512, 1024, 2048 and 4096; if logical
                         block size is 8192, 8192 is also a legal
                         value. The default is 1024.

and reformat the cache partitions with the '-f 8192' option (though I'm
waiting for the cache disk to fill up to confirm that it's a cure).
Alternatively, reduce the cache size to the point at which it's not a
problem, though I'm afraid you'll have to find out for yourself how far you
can push things....

-- 
--------------- Robin Stevens  <robin.stevens@oucs.ox.ac.uk> -----------------
Oxford University Computing Services  http://www-astro.physics.ox.ac.uk/~rejs/
 (+44)(0)1865: 726796 (home) 273212 (work)  273275 (fax)  Mobile: 07776 235326