No. of inodes at filesystem generation

[Ralph Grothe]

Hi foromers,

due to disk space shortage I was forced to extend a couple of filesystems used by an SAP/Oracle DBMS.

Unfortunately those guys who set the db server up weren't farsighted enough to use the -e flag of the vgcreate command together with a sufficiently high value for max PEs/PV.
If they had done so it would have saved me a lot of time, and I could have easily extended the respective LVs by a mirror copy online.
Since the Max PE value was too low for this, I had to be given a downtime and create a new VG to copy some 50 GB onto the newly created LVs in this VG. :-{

When I created the filesystems in those new LVs it seems that I haven't been considerate enough because I silently relied on the newfs command, not taking into account that the underlying mkfs_vxfs would offer more control. :-(

Thus I only used the following options

newfs -F vxfs -o largefiles -b 8192 /dev/vgE01/rlvol*

Now I fear this was a mistake, because when I look at the maximum number of inodes this looks a bit sparse.

Here are the 1st, 6th, and 7th col filtered of the "bdf -i" command for filesystems in this VG:

# bdf -i /dev/vgE01/lvol*|awk 'NF==9{printf"%10u%8u%8u\n",$2,$6,$7}'
1564672 2336 36320
1024000 288 25536
28672000 544 206656
1048576 2592 23872
524288 800 16000
2023424 32 63136
8192000 32 255808
516096 1824 5952
2154496 14368 13344
1130496 3872 5152
73728 32 608
73728 32 928
73728 32 928
73728 32 928
3072000 800 47040

Wouldn't you agree that the values in the last column are a little too low for the smaller filesystems?

On the other hand, in the manpage of mkfs_vxfs it reads for the ninode option:


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.
For a Version 2 or 3 disk layout this is the
maximum number of inodes, The number 0 and
the string ``unlimited'' are interpreted to
mean that the number of inodes is unlimited.
The default is ``unlimited'' for a Version 2
or 3 disk layout.


What the hack is a Version 2|3 disk layout?
And why wasn't the default unlimited number set when I created the filesystems?
Will the number grow when I do an extendfs?

Regards
Ralph

[Patrick Wallek · Accepted solution]

Using vxfs filesystems, my understanding is that there is no set value for the maximum # of inodes, they are created as they are needed. You should have no worries about running out of inodes using a vxfs filesystem.

[Mark van Hassel]

Correct,

The with vxfs, you don't have to worry about the maximum number of inodes. The version lay-out is the version of vxfs. You can check this with fstyp -v [rlvol]

[Sridhar Bhaskarla]

I am not worried about the inodes on vxfs filesystems. They will ofcourse be increased as and when you run extendfs. And there will not be any such errors that a file system is full because it is running short of inodes.

-Sri

[Volker Borowski]

Hi Ralph,

this might be a matter of uninterest, but ....

Why didn't you create a new volume group, with new disks and new filesystems in it ?
I think this would have saved you a lot of work.

Volker

[Wodisch]

Hello Ralph,

you could set the maximum amount of inodes per
VxFS filesystem, but the default is "unlimited"
and as long as you have free space, you will
get another "Allocation Unit" containing more
inodes...

But have a look into the "mount_vxfs(1M)" options:
- if you do have the "Online JFS" consider
using "convosync=direct,mincache=direct" in
addition to the ones you already use, for the
filesystems containing ONLY Oracle data files,
at least.

HTH,
Wodisch

[Ralph Grothe]

Hi Volker,

that was what I did.
After our EMC storage admin had bound a new "disk" for me I created a new VG consisting of this "disk".
But I still had to work in the DB's offline mode (which ment yet another late shift for me) in order to copy all files from the ten LVs of the old VG to the LVs of the new.
Compared to a simple "lvextend -m1" in a for loop over the old VG's LVs, as I would have done, had I only been able to mirror (see above), this was much more work.

[Ralph Grothe]

Hi Wodish,

thanks for the hint about the convosync and mincache options.
Unfortunately, on this box there isn't OnlineFJS available, but I will remember these opts for our other boxes that do run under OnlineJFS.
Btw, I do read the manpages, because it's fun to learn about all the interesting features and options of commands (do you know all the flags of the ubiquitious ls command?).
I think to have read in a Unix book some time ago that what distiguishes the Unix "gurus" from the ordinary Unix folks is that the first simply do read the manpages ;-)
(that said does not remotely imply that I consider myself belonging to the first, though)