HP-UX 11.00 compatibility with VXFS version 4

[Stephen Wood_3]

On an HP-UX 11.00 9000/800, the OS runs out of inodes on my VXFS version 4 RAID, which was built elsewhere on an HP-UX 11.11 system. However, both 'df -i .' and 'bdf -i .' reported 17M inodes allocated, 9M free, 8M (but NOT a magic number like 2**33) used.

The troublesome VXFSv4 RAID is 1.4TB. A VXFSv3 0.7 TB RAID, with more than 11M inodes used, behaves normally [except for df's use of free inodes rather than total inodes in the divisor when computing %used].

Is this a failure of the OS to deal properly with VXFSv4? Is there an applicable patch?

The system runs a legacy application; migration to HP-UX 11.11 is not in the cards.

[Bill Hassell]

VxFS filesystems, unlike HFS filesystems, allocate inodes dynamically as needed. This means that the free indoe numbers from bdf or df are not meaningful. Inodes will continue to be created as required until the disk is full.

[Stephen Wood_3]

I wasn't clear about the problem.

The problem is that the OS refuses to create any more files, declaring that it is out of inodes, even though the the RAID is only 80% full (1.4TB allocated, 1.1TB used).

[A. Clay Stephenson]

You should look for any vxfs 11.0 patches but my rule is that filesystems are always created on the oldest HP-UX platform so that upward compatability exists.

One non-obvious "gotcha" is that the largefiles option is required for large numbers of inodes eventhough no large files are actually on the filesystem. The internal structures which house the inode list must be allowed to grow beyond the 2GB limit. That was a "feature" I fought foe a good while before I stumbled onto enabling largefiles eventhough I didn't actually have any largefiles on the filesystem. It would also be nice to know is your filesystem was created with dynamic inode allocation or static inode allocation via the inode=xxxxx argument. I would run mkfs -F vxfs -m on both platforms and see if there is a difference. Note that -m will not create a new filesystem but rather will display the options used when an existing filesystem was created. Man mkfs_vxfs for details.

[Sandman!]

Hi Stephen,

Could you post any errors related to inodes in the syslog.log file. Is there any filesystem on which this error is occuring because in that case you can run the following command to find out the attributes with which that particular filesystem was created:

# mkfs -F vxfs -m

Reason I say so is because this filesystem may have been created w/o largefiles support and in order to dynamically grow beyond the 8M inode limit, you need to enable largefiles on the filesystem.

cheers!

[Stephen Wood_3]

mkfs -F vxfs -m /dev/vg03/lvol1 > mkfsinfo.txt yielded the following:

mkfs -F vxfs -o ninode=unlimited,bsize=8192,version=4,inosize=256,logsize=256,nolargefiles /dev/vg03/lvol1 1464991744

Did you mean that remounting it with the 'largefiles' option specified at mount time would clear up the problem? Or did the specification of 'nolargefiles' when the FS was created preclude that possibility?

[A. Clay Stephenson]

The largefiles mount option doesn't do what you think it does, it doesn't enable or disable largefiles on the filesystem. You need to run "fsadm -F vxfs -o largefiles /mountpoint" on the mounted filesystem to convert it to largefiles.

[Sandman! · Accepted solution]

See fsadm_vxfs(1M) for details and it'll tell you exactly how to go about enabling largefiles on the filesystem throwing this error.

# fsadm -Fvxfs -olargefiles

Also take a look at TKB doc UFSKBRC00010611...

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000080062166

cheers!

[Stephen Wood_3]

[A. Clay] Stephenson and Sandman both provided solutions; the document to which Sandman referred provided information that leads to a plausible explanation of why the solution (presumably) will work.

The VXfS in question ran out of inodes shortly after 8M, even when there was still 290GB of disk space available. Unmounting the VXfS, using fsadm to enable largefiles, changing /etc/fstab to specify largefiles, and remounting the VXfS apparently solved the problem. The reason this works: HP-UX uses a file on the file system itself to store the inode information, presumably at 256B per inode; thus for the number of inodes to exceed 8M, this file must exceed 2G. The OS was perfectly happy to allocate more inodes, but the FS wouldn't allow the file storing them to grow.

Whether this will truly solve the problem has not been tested; if it fails, then I will re-open the thread.