file system out of inodes

[Rigoberto Barocio_1]

Hello, this is my error on syslog.

OLDsyslog.log:Sep 30 14:14:32 ategS241 vmunix: msgcnt 1 vxfs: mesg 011: vx_noinode - /archives/ategs241 file system out of inodes

The result of BDF -i
Filesystem kbytes used avail %used iused ifree %iuse Mounted on
/dev/vg03/lvol1 71671808 29886367 39303617 43% 7865449 10446359 43% /archives/ategs241

It's strange becouse the bdf -i showme that i have free inodes, exist some kernel parameter to tunning this or why my system report that error.

thanks.

[Pete Randall]

Could this be because you're looking at OLDsyslog.log, dated Sept 30th and comparing it to current usage?


Pete

[Rigoberto Barocio_1]

Yes, this is my oldlog becouse i delete some files to release space, the bdf -i showme the almost the same information % of inodes usage.

[Pete Randall]

So, when did you run the bdf? Today? If so, you're comparing the condition today, which shows only 43% of the inodes in use, with the conditions on Sept 30th, when there were no inodes available.

Or are you asking how to make more inodes available so you won't have this problem in the future?


Pete

[Rigoberto Barocio_1]

Thanks Pete, don't have the bdf -i of Sep30 but
i remember very well that the result of bdf -i are almost the same % of inodes free.

And i want to know how to make more inodes available, thanks Pete.

[Pete Randall]

To increase the number of inodes available, you need to increase the kernel parameter ninode, build a new kernel and reboot off the new kernel - best done through SAM.


Pete

[Rigoberto Barocio_1]

ninode defines the maximum number of open inodes that can be in memory.

Sorry for this question.
What is the relation with ninode(kernel parameter) and maxinodes on a filesystem with vxfs.

[Pete Randall]

The ninode parameter controls the number of inodes available to HFS file systems. For VxFS file systems, the inodes are created dynamically and you shouldn't run out.

What does "fstyp /dev/vg03/lvol1" return?


Pete

[Rigoberto Barocio_1]

# fstyp -v /dev/vg03/lvol1
vxfs
Cannot open /dev/vg03/lvol1: Invalid argument
Cannot open /dev/vg03/lvol1: Invalid argument

version: 4294967295
f_bsize: 8192
f_frsize: 1024
f_blocks: 71671808
f_bfree: 41785441
f_bavail: 39173851
f_files: 18830872
f_ffree: 10446360
f_favail: 10446360
f_fsid: 1073938433
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 0
f_fsindex: 7
f_size: 71671808

[Pete Randall]

I believe that is telling us that it is a VxFS file system. Try running fstyp again without the "-v" option. And try running it against the raw device /dev/vg03/rlvol1, too.


Pete

[Rigoberto Barocio_1]

# fstyp /dev/vg03/rlvol1
vxfs

# fstyp /dev/vg03/lvol1
vxfs

It's vxfs.

[Pete Randall · Accepted solution]

OK, that means that inode allocation will be dynamic and you should not run out. The message you're seeing in OLDsyslog must have occured just before more inodes were dynamically allocated.


Pete

[Rigoberto Barocio_1]

Ok thanks Pete, i just read the vxfs documentation for inode automatic allocation.
thanks.

[A. Clay Stephenson]

Actually, inode allocation on a vxfs filesystem is not necessarily dynamic although that is the default. If you specify a non-zero ninode=nnn value when the filesystem is created then the number of inodes is fixed at nnn. To determine if this is the case for the filesystem in question, run this command:
newfs -F vxfs -m /dev/vgxx/lvolN

Make certain that you specify "-m" which will not create a new filesystem but will display the options used to create the existing filesystem. You do not need to unmount the filesystem. Man mkfs_vxfs for details.

[Ken Stailey]

I have an 11i system that logs messages about running out of inodes but when I run "bdf -i" (or GNU "df -i") there are over 100,000 free inodes reported.

This is not a timing error. When the filesystem is in this state "touch" will fail to create new files.

I think this bug existed in 11.00 and possibly in 10.20 too. These are very large filesystems as witnessed by the "fstyp" output. We never run either of the fsadm "-d" or "-e" functions.

Particulars:

Running "/usr/sbin/mkfs -F vxfs -m /dev/vgfbr2/rlvol17" reports:

mkfs -F vxfs -o ninode=unlimited,bsize=1024,version=4,inosize=256,logsize=1024,nolargefiles /dev/vgfbr2/rlvol17 131072000

Running "fstyp -v /dev/vgfbr2/rlvol17" reports:
vxfs
version: 4
f_bsize: 8192
f_frsize: 1024
f_blocks: 131072000
f_bfree: 4655454
f_bavail: 4364745
f_files: 9547348
f_ffree: 1163860
f_favail: 1163860
f_fsid: 1074200593
f_basetype: vxfs
f_namemax: 254
f_magic: a501fcf5
f_featurebits: 0
f_flag: 0
f_fsindex: 7
f_size: 131072000

Running "fsadm -F vxfs -D /mnt" reports that there are:
dirs searched 1842422
total blocks 161121
immed dirs 1763792
immeds to add 31
dirs to reduce 1128
blocks to reduce 1157

Running "fsadm -F vxfs -E /mnt" reports that there are:
Total Files 4355682
Average File Blks 28
Average Extents 1
Total Free Blks 4654666
blocks used for indirects: 176
% Free blocks in extents smaller than 64 blks: 5.26
% Free blocks in extents smaller than 8 blks: 0.53
% blks allocated to extents 64 blks or larger: 88.34

[Bill Hassell]

From your fstyp command, it looks like you have hit a largefile limit. The lvol is set to "nolargefiles" which not only affects ordinary files but also limits the number of entries in the directory. VxFS allocates inodes as needed so bdf's listing is not meaningful for VxFS. Once the directory (which is also a file) reaches the nolargefiles limit of 2Gb, no more entries can be made. Change the filesystem to allow largefiles and all should be well again. Just to be cautious, I woul backup the filesystem first. fsadm can modify the largefiles option.