FreeBSD 5.4 no inodes left

[Jerry McAllister]

On Wed, Sep 20, 2006 at 11:14:38AM -0700, Alex Franks wrote:

> 
> 
> -----Original Message-----
> From: owner-freebsd-questions at freebsd.org
> [mailto:owner-freebsd-questions at freebsd.org] On Behalf Of Philip Radford
> Sent: Wednesday, September 20, 2006 7:55 AM
> To: freebsd-questions at freebsd.org
> Subject: FreeBSD 5.4 no inodes left
> 
> Hi All,
> 
> I am running FreeBSD 5.4 and have recently received the following
> message on our box for the /var partiton.
> No inodes left.
> 
> I have checked the statistics and there was an apache httpd log which
> was maxing out the usable space. I have since removed this file and the
> available space has dropped to over 50%. However I still get the 'no
> inodes left' message even though I have freed the space.
> 
> Does anyone know how I can get the inodes to be freed up on the /var
> partition.

Yes.    Delete some files.

Then, when you have it cleared up temporarily (deleting files is
only a brief temporary fix), back the file system up somewhere and
remake it.   In the newfs command, use bytes, block-size and frag-size
arguments to force it to create more inodes in the filesystem and 
then restore the backup.   Possibly just setting bytes=2 will be
enough to cover it, but you may also need to set block-size=8192
and frag-size=1024 (which is kind of small). 

If you run out of inodes, it tends to mean you are creating a lot
of small files.    This can happen with some utilities that create
a new file for each piece of data.    But, the default values for
bytes, block-size and frag-size usually provide plenty of inodes
for most things.   So, maybe some job you are running is overdoing
creating small files for some reason or you have a database designed
less efficiently or something.

By using a smaller block and fragment size, you get more inodes, but
you make reading and writing large files less efficient.  Of course,
if you have a hoard of small files, that isn't important.   In fact,
if the file system if full of small files, then it is less efficient
to have large block and fragment sizes.

////jerry

> 
> Thanks in advance.
> 
> Regards
> Phil.
>