We recently got an issue with adpatch, it is failing to read driver files from APPL_TOP or unable to write to adworker log files, when the affected files have 64 bit inode numbers.
As per my findings, 32 bit EBS products cannot process files with 64 bit inode number (> 2^32 or 4.3 Billion) there is a kernel parameter to mimic 32 bit inode numbers as per - Adpatch error on NFS share "Apparently not all Zip files for this patch have been unzipped" (Doc ID 2500552.1) -- Set the OS boot kernel parameter nfs.enable_ino64=0 so that the NFS client will fake up a 32-bit inode number for the readdir() and stat() syscalls instead of returning the full 64-bit number
But the number of files in /u01 mount point (where APPL_TOP and rest of the file system is located) is around 6.3 million, and the inodes used are 12 million, but still I cannot understand why the new files are getting generated with inode numbers greater than 2^32 (4.3 Billion)
[oracle@hostname u01]$ df -i .
Filesystem Inodes IUsed IFree IUse% Mounted on
nfs_ip:/u01 9223372036854775807 12876764 9223372036841899043 1% /u01
[oracle@hostname u01]$ df -h .
Filesystem Size Used Avail Use% Mounted on
nfs_ip:/u01 50T 1.6T 49T 4% /u01
[root@hostname ~]# cd /u01
[root@hostname u01]# find . |wc -l
6294824
[oracle@hostname apps_st]$ touch one
[oracle@hostname apps_st]$ ls -ltri one
4540493156 -rw-r--r--. 1 oracle oinstall 0 May 20 15:52 one
[oracle@hostname apps_st]$
The files which adpatch can successfully read have inodes less than 2^32 like adalldefaults.txt, but still a pretty high inode value
[oracle@hostname XXXXX]$ ls -li adalldefaults.txt
2854884505 -rwxr-xr-x. 1 oracle oinstall 25227 Jan 20 08:17 adalldefaults.txt
[oracle@hostname XXXXX]$ ls -li tmpdef.txt
4363492703 -rwx------. 1 oracle oinstall 1989 May 10 07:46 tmpdef.txt
[oracle@hostname XXXXX]$
Can someone clarify, why the inode number generation is very high even though the number of files are far below 2^32.
How to get the inode number generation to a lower value?
Also, as per df -h output 1.6 TB storage is utilized, but I moved some of the APPS backup folder which is occupying around 800 GB to another mount point, but still I see the utilized space is 1.6 TB.
This instance was working fine since few years, we recently ran into this issue without changes to underlying storage.
Environment:
/u01 : NFS mount point
EBS : 12.1.3
OS: RHEL 7
Thank You
