AIX Version 6.1 and 7.1.
I understand that when the OS initially creates the FS and inodes, its pretty strict, but not always tuned to a 1:1 ratio. I see the same thing when adding a whole disk LV to a separate device.
It seems that when we expand a filesystem the inodes don't get tuned appropriately. So we end up with a 100% inode table full with a % of FS still available.
I know under some other OS's they have like tunefs or other type of filesystem maintenance to help with the inodes to FS space allocation.
What does AIX provide to do the same. getting kinda tired of seeing a 12gb root (/ fs) full with only 67% fs full and a 100% inode table full. I cannot expand the filesystem any more due lack of free PP's.
I would seriously worry why you think you need a 12Gb root filesystem.
You should only have files necessary for the OS boot in the root filesystem, ideally with home directories, /usr, /var and /tmp in separate filesystems. Perhaps you should focus on removing non-OS files from the root filesystem.
How do you prepare for disaster recovery? Is your mksysb excluding huge sections of the root filesystem? If so, it would be better to get them into their own filesystems and leave root alone. Have a look in /etc/exclude.rootvg to see what you leave out of a mksysb
What you are looking for ist the chfs command, but your question gives the possibility to explain some general concepts. Bear with me if i tell things you already know, it might be of benefit to others.
When a file is stored on disk not only its data get stored, but also "data about the data" or "meta data" for short: the files name, its creation date, ownership and so on. The data itself is stored in what you call a "file", the meta data are stored in a data structure of the filesystem called "Inode".
The main difference between "normal" filesystem space and the inodes is that FS space is a contiguous resource: every file takes out as much as it needs. Inodes are a record-like structure and they are distinct: they can either be occupied or empty, but there is always a limited number of them.
Typically, when a filesystem is created, a certain number of these inodes are created and then used as files get stored in the FS. How many in fact are needed is a matter of educated guesswork on the side of the sysadmin: in most filesystem creation tools some sensible defaults are built in. If you know the FS will hold only a few very large files (like i.e. DB data files) you can reduce the number of inodes, wasting less space for these leaving more FS space to be used for file content. If you know there will be many small files you may need to increase this number, otherwise you might run out on Inodes before you run out of disk space.
In classical filesystems (this is not only true for JFS, but also the filesystems of other Unixes and Linuxes: sfs, zfs, e2fs, ....) the number of Inodes was defined upon creation time of the FS and fixed: typically the FS creation program had some default built in, which created one Inode for every X kb of disk space (the defaults varied but the principle was always the same). This default could be changed by a set of command line switches should the need arise (for special cases like the ones mentioned above).
With the possibility of dynamically growing FSes (historically an FS could only be grown offline, while it was not mounted) the possibility arose that the originally calculated defaults for the ratio of inodes vs. FS space became invalidated. IBM reacted to this with the JFS2 file system: part of its innovations was that the number of inodes will now be dynamically adjusted. You do not need to change that manually any more. padow has pointed that out in post #2 already.
So, if you still have one of the old JFS filesystems: get a downtime, change the JFS to JFS2 and don't be bothered with it any more. JFS2 has several other advantages over JFS, so this will be beneficial in other regards too. This may mean having to reinstall the OS, because all the recent OS versions i know of already use JFS2 for the rootvg FSes.
The notion of Robin is absolutely correct, btw.: if you need 12G in your "/" FS you are doing something seriously wrong. Even yy biggest DB system (like every other system i run) has a "/" FS of 256MB, which is absolutely sufficient! Everything not part of the OS is put into separate FSes and even separate VGs. You do not want to mix up OS and application data.
And figure out what on earth you have in root using 12GB. To echo bakunin, that's... not right. Maybe a file system isn't mounted and files have been written into a directory meant to be a file system (mount point), in which case there is probably a permission issue on the underlying mount point's directory (or the 12GB was written by root)
I would seriously worry why you think you need a 12Gb root filesystem.