How to increase inodes on HFS filesystem

[jerry1]

I have a partition that has run out of inodes.
It is an hfs filesystem:

/dev/dsk/c2t2d2 /pbqtmp hfs rw,suid 0 1


I tried using:

fsadm -F hfs -o largefiles /dev/rdsk/c2t2d2

But it still show no more inodes:

# bdf -i /pbqtmp
Filesystem kbytes used avail %used iused ifree %iuse Mounted on
/dev/dsk/c2t2d2 2006553 1063477 882879 55% 329600 0 100% /pbqtmp

[Sandman! · Accepted solution]

Need to add more space to hfs filesystems in order to increase the inode allocation. The largefiles option is good only for vxfs filesystems.

[jerry1]

It's only 55% used:

/dev/dsk/c2t2d2 2006553 1063477 882879 55% /pbqtmp

[A. Clay Stephenson]

Why in the wide world of sports did you create a non /stand hfs filesystem? You would be better advised to backup this filesystem; recreate it as a vxfs filesystem (which, by default, dynamically increases the number of inodes on demand); and restore from backup.

In any event, the ratio of filesystem size to inodes (default 6144 bytes per inode) is set when the filesystem is created and can't be increased. If you add more blocks to the file system via extendfs, it will add more inodes but only in the same proportion as when the filesystem was created.

You can get a bit more data with:
fstyp -v /dev/dsk/c2t2d2

[jerry1]

Clay, your a good man. But! Never assume.
I inherited this piece of junk.
It's running HP-UX 10.20 and all the
partitions are hfs for some reason.

[James R. Ferguson]

Hi Jerry:

I agree with Clay. Never mind that it's 10.20. VxFS (JFS) filesystems were supported at that point. I'd backup your data; 'newfs' a JFS filesystem; and restore your data!

Regards!

...JRF...

[TwoProc]

I'm with the gang on this.
JFS worked fine for me running Oracle on 10.20, and it should be fine to convert to.

If you're sticking with hfs:
man mkfs_hfs - see the option for nbpi.

[jerry1]

Ah. Easier said than done. I do not have the
luxury of just shutting down a server that
is running production and rebuilding.
Management does not understand and does not
care. There attitude here is run it till it
dies.

[A. Clay Stephenson]

Ok, you now have a situation where you cannot increase the number of inodes substantially without substantially increasing the size of the filesystem. Sadly, you are using the whole-disk layout rather than LVM so you can't increase the filesystem size without increasing the size of the disk.

There are really only a few of viable options. 1) Backup; build a new filesystem (hfs of vxfs but you know what I think); restore. 2) If you have room on other filesystems, copy directory trees under the existing filesystem to other filesystems; delete the existing filetrees; setup symbolic links pointing to the new locations.
3) If you have free disks or LVOL's, create new filesystems; copy directory trees to them; remove the directory trees; make the new filesystems mountpoints under the old.

[A. Clay Stephenson]

... oh, and one more thing, Jerry. Someone less polite and less tactful than I would point out that there should have been monitoring scripts/traps in place that would have warned you in advance that your filesystems or other resources were nearing limits so that you could deal with them before they became critical --- but I would never tell you that (though I might think it).

Regards, Clay

[whiteknight]

Hi Jerry,

You may consider using vxfs, which is more robust and stable, you will not face out of inodes issue.

[Dennis Handly]

>Clay: there should have been monitoring scripts/traps in place that would have warned you in advance ...

I have such a script and it warns me every day.
I just now realized that for vxfs, I don't care about inode precentage, thanks.

[Dennis Handly]

I forgot to mention one way to "increase" the inodes is to decrease the number of files.

You can tar gzip small files into one big file.

[A. Clay Stephenson]

Dennis, my monitors for vxfs filesystems also monitor inode usage as well as size limits because it is possible to create a vxfs filesystem with static inode allocation --- it's dumb to do it but it can be done.

[Juan M Leon]

Jerry this is a thoug.
I see that you FS is 2GB and if you have at least 2 hours fo downtime (lets say weekly/monthly reboot) I will use my spare disk and use the following command to restore my data on different FS

find . -xdev -depth -print | cpio -pdum {dest_dir}

Once complete you can always unmount the old FS and mount the New FS.

I hope it helps.

[Dennis Handly]

>Clay: because it is possible to create a vxfs filesystem with static inode allocation

Do you know how to check the filesystem to determine that? I assume this is: mkfs -m

[jerry1]

I changed /etc/default/fs entry to be
vxfs from hfs. Created volume group with
the disk in question.
Also going to mount other critical
production partition to NAS via NFS(no
fiber to this box) and use that 4gig drive
to mirror the 4gig boot drive.

[A. Clay Stephenson]

mkfs -m works (and is the only approach outside of C that I have found) but my approach is to do an fstyp -v and simply see if f_favail is below some threshold. I haven't delved into the bowels of vxfs internals but it has been my experience that the dynamic growth occurs before f_favail gets too low. All of this is largely academic because the last version of vxfs that allowed fixed inodes was 11.11; under 11.23 and up, you can still specify ninode=n (eventhough it is not documented) but the option is ignored.