Re: [cobalt-users] RaQ4 with latest kernel just installed reports /home partition full when not

["Steve Werby" <steve-lists@xxxxxxxxxxxx>]

"Steve Werby" <steve-lists@xxxxxxxxxxxx> wrote:
> Earlier today I was preparing to install a newer version of Python and the
> latest version of Mailman on a client's RaQ4 (RaQ4 hardware and RaQ4
> software).  Part way through unpacking the source tarball for Python onto
> the /home partition, tar starting issuing error messages like the
following:
>
> tar: Python-2.2.2/Tools/unicode: Cannot mkdir: No such file or directory
> Python-2.2.2/Tools/unicode/makeunicodedata.py
>
> So I checked partition usage.
>
> Filesystem            Size  Used Avail Use% Mounted on
> /dev/hda1             726M  617M   71M  90% /
> /dev/hda3             194M   19M  165M  10% /var
> /dev/hda4             8.2G  2.6G  5.1G  34% /home
>
> Not only did the /home partition have plenty of space, but the other
> partitions did as well.  I tried creating a directory and a file within
the
> /home partition to see if that was possible (both failed).

The client's data center tech did some diagnostics and it turns out the
drive was full.  Unfortunately I didn't think to check for an inode (file)
limit.  Running df for inodes instead of blocks on the server outputs:

[root /tmp]# df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hda1             192512   37193  155319   20% /
/dev/hda3              51376     932   50444    2% /var
/dev/hda4              67456   67456       0  100% /home

So the partition had hit its inode limit!  However that's an awfully low #
of inodes!  8.2 GB => 67,456 inodes?    Here's the output for a /home
partition on another RaQ4 about double in size:

[root tmp]# df -h /home
Filesystem            Size  Used Avail Use% Mounted on
/dev/hda4              17G  7.5G  9.3G  45% /home

And its inodes:

[root tmp]# df -i /home
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/hda4            4621888   34416 4587472    1% /home

Hmm.  17 GB => 4,621,888 inodes.  The data center tech said that it appears
to be the result of the # of inodes being set incorrectly during the format
phase of the OS restore process (via the OS restore CD) before the machine
was put into service for my client.  The tech suggested that the only way to
resolve would probably be to format the drive, though he also suggested that
pulling the drive and running Norton Ghost 2003 to image it to another drive
may be worth a shot, though he believes it will create an exact duplicate.
As there are very good recent backups and this is low risk, I think it's a
good alternative though I can't say from experience whether it will work
since I've never encountered a drive with the inodes set so low.  Anyone
have a similar experience and/or suggestions?

If nothing else, hopefully this will benefit anyone else who runs into this
issue.  I'd only seen one other RaQ hit the inode limit and that was due to
some very specific testing we were doing, not normal usage.

--
Steve Werby
President, Befriend Internet Services LLC
http://www.befriend.com/