total number of inodes is decreasing

[Sandra_8]

Hi all,

I having a problem with the total number of inodes in /home file system, they seem to have decreased since I created the file system. This is the output I get from "df -t" after installing the OS:

$ df -t
/home (/dev/vg00/lvol5): 382570 blocks 50994 i-nodes
516096 total blocks 52368 total i-nodes
108126 used blocks 1374 used i-nodes
4 percent minfree

As we can see the total number of inodes was 52368.
Now the output appears this way:

$df -t
/home (/dev/vg00/lvol5): 51674 blocks 6877 i-nodes
516096 total blocks 8820 total i-nodes
461052 used blocks 1943 used i-nodes
0 percent minfree


The total number of inodes now is 8820. How can it be posible that the total number of inodes is decreasing. I was thinking that just the number of used inodes should decrease. It this normal or could it be a bug with df command? The output got with bdf command is the same.

Any help will be apreciate. Thanks.

[Paula J Frazer-Campbell]

Sandra

From Man df

-t Report the total allocated block figures and the
number of free blocks.


Whereas


-i Report the total number of inodes, the number of
free inodes, number of used inodes, and the
percentage of inodes in use.


Do you have a df -i from build time to compare with a df -i from now?

Paula

[Duncan Edmonstone]

Two quotes from the mkfs_vxfs man page:

Inode allocation is done dynamically. There are a minimum number of
inodes allocated to the file system by mkfs, and any other inode
allocations are done on an as-needed basis during file system use.

ninode=n
n is the maximum number of inodes in the file
system. The actual maximum number of inodes
is n rounded up to an appropriate boundary.
The digit 0 and the string unlimited both
mean that the number of inodes is unlimited.
The default is unlimited.

from the man page for df_vxfs :

On a Version 2 or greater disk layout, VxFS dynamically allocates
inodes from the pool of free blocks, so the number of free inodes and
blocks reported by df is an estimate based on the number of free
extents and the current ratio of allocated inodes to allocated blocks.
Allocating additional blocks may therefore decrease the count of free
inodes, and vice versa.

HTH

Duncan

[Steve Steel]

Hi

This is a known confusion concerning the functioning of vxfs

bdf and df show the current number of inodes and not the maximum .When the current number is exceeded vxfs increases the number of indoes upto the maximum as specified in the mkfs command (or unlimited if ninode is not specified).

vxfs allows inodes creation as long as there are free blocks available.

Steve Steel

[harry d brown jr]

Sandra,

here is a sample of df and bdf:

# df -i /var/appl
/var/appl (/dev/vg00/lvol12 ) : 1023388 total i-nodes
1016392 free i-nodes
6996 used i-nodes
0 % i-nodes used
# bdf -i /var/appl
Filesystem kbytes used avail %used iused ifree %iuse Mounted on
/dev/vg00/lvol12 4096000 30430 3811523 1% 6996 1016392 1% /var/appl
# df -t /var/appl
/var/appl (/dev/vg00/lvol12): 7623046 blocks 1016392 i-nodes
8192000 total blocks 1023388 total i-nodes
60860 used blocks 6996 used i-nodes
6 percent minfree

#


live free or die
harry

[Sandra_8]

I don't have a df -i from build but I suppose It was the same that df -t as long as, right now, I get the same with df -i or df -t.

One thing that I can't understand is what is the TOTAL number of inodes used for if it changes? Besides, this value should never decrease, supposing the file system runs out of inodes this TOTAL value may increase but never decrease.

[MANOJ SRIVASTAVA]

Hi Sandra


Does the system panic ? As per one tech document

"Panics resulting from system memory corruption, specifically
of the 32-byte malloc free pool. This defect has many
failure symptoms, resulting in different system [panic]
messages. The memory corruption was the result of
simultaneous access to files on a filesystem when it was
being unmounted. "

you may like to look at this :

http://us-support.external.hp.com/cki/bin/doc.pl/sid=f18f2a370634251e23/screen=ckiDisplayDocument?docId=200000048680095


Manoj Srivastava

[James Murtagh]

Actually, this is not unusual and makes sense looking at your figures. Since your filesystem was created, the block size has increased greatly but the inodes used not so....you seem to be creating a small number of large files.

I assume you have OnlineJFS and have restructured your filesystem using something similar to :

fsadm -F vxfs -E -D /home

This will note your sapce is increasing but inodes not, and reallocate according to maximise your disk space. Note the minfree value has also decreased.

Just to prove this, I created some large files in my home directory using prealloc, and restructured my filesystem. My total inodes fell from 4775 to 220.

Regards.

[sandra_9]

You are right James, I have quite big files in this file system but.... I haven't used OnlineJFS or anything similar at all.
I have prove to move some files from one file system to another and I've seen that the number of TOTAL inodes increase in the origin file system and decrease in the destiny file system. It seems that the system is changing the number of TOTAL inodes dinamically which doesn't seem logical at all because only the number of USED and FREE inodes should vary and not the total number of inodes.
As I don't know the total number of inodes to calculate if the number of free ones is enough, I hope I can trust the percentage I obtain with df -i

[James Murtagh · Accepted solution]

Hi Sandra.

I wouldn't worry about this, it is simply a feature of the Veritas File system.

It dynamically evaluates projected usage of the filesystem using parameters such as filesystem size, used blocks and used inodes. As you moved the files to the new filesystem for example, the free space in the filesystem decreased, and depending on the average sizes of the files, would have re-evaluated your inode needs appropriatley. Remember inodes take up space in the filesystem and if your a using few inodes but lots of filesystem blocks, it makes sense to free some up.

From a user point of view, the fact the release notes state the inode allocation can be done dynamically and online restructuring can take place, should aleviate most concerns you have.

If you want some more in depth information on how this works, please let me know.

[sandra_9]

Hi James,

I would highly apreciate all information you can give me about this.
The problem is that I have to throw alarms of system status so I need to know if the amount of free inodes are enough or not. Right now I was calculating the percentage of free inodes with the total value from build (which I thought was not going to change) and the number of current free inodes, as you can suppose this is failing because the TOTAL number of inodes is changing. So... it would help me a lot to know as much as I can about how this works. I would like to know which is the fixed MAXIMUM number of inodes?
Thanks a lot.

[James Murtagh]

Hi Sandra.

To be honest I wouldn't monitor inode allocation on vxfs filesystems for the reasons you have already seen. One of the features of JFS was to take this administrative duty out of filesystem management, as it was troublesome to re-create HFS filesystems just to increase the inode allocation. Take it for granted you will always have enough inodes in these filesystems.

When you create a vxfs filesystem, it is broken up into Allocation Units (AU) of 32000 blocks, each block being 1K in size. That is why it is recommended creating vxfs filesystems in multiples of 32MB, as sometimes there can be problems reducing filesystems when the last allocation unit is not 32MB.

In the structural area of the filesystem there is an Object Location Table (OLT) that holds such tables as the Inode List, Current Usage Table etc. These hold information about the layout of the AUs.

When, for example, large files are moved to a JFS filesystem, they will be located in one of the AUs. As extents are dynamic, they will be allocated larger extents to keep the data contiguous and localised. In this case, the inode allocation for this AU will be decremented as there is no need for lots of inodes allocated to this area when it is occupied by a small number of large extents, and vice versa with small files.

However, one of the downsides to this is that the filesystem can become fragmented due to all this restructuring. Hence, products such as OnlineJFS can dynamically re-organise the filesystems to keep the data localised, ie subdirectories under directories physically on the disk.

I hope this made some sense.....