我们最近遇到了 adpatch 的一个问题，当受影响的文件具有 64 位 inode 编号时，它无法从 APPL_TOP 读取驱动程序文件或无法写入 adworker 日志文件。
根据我的发现，32 位 EBS 产品无法处理具有 64 位 inode 编号的文件（> 2^32 或 43 亿），有一个内核参数可以模拟 32 位 inode 编号，如 NFS 共享上的 Adpatch 错误“显然，此补丁的所有 Zip 文件都未解压”（文档 ID 2500552.1） - 设置 OS 启动内核参数 nfs.enable_ino64=0，以便 NFS 客户端为 readdir() 和 stat() 系统调用伪造一个 32 位 inode 编号，而不是返回完整的 64 位编号
但是 /u01 挂载点（APPL_TOP 和文件系统其余部分所在的位置）中的文件数量约为 630 万，而使用的 inode 数量为 1200 万，但我仍然不明白为什么生成的新文件的 inode 编号大于 2^32（43 亿）
[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]$
adpatch 可以成功读取的文件的 inode 小于 2^32，例如 adalldefaults.txt，但 inode 值仍然很高
[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]$
有人可以解释一下为什么即使文件数量远低于 2^32，inode 编号生成量却很高。
如何让 inode 编号生成为较低的值？
此外，根据 df -h 输出，已使用 1.6 TB 存储空间，但我将占用约 800 GB 的部分 APPS 备份文件夹移动到另一个挂载点，但我仍然看到已使用的空间是 1.6 TB。
这个实例几年来一直运行良好，最近我们遇到了这个问题，而底层存储没有发生变化。
环境：
/u01 : NFS mount point
EBS : 12.1.3
OS: RHEL 7
谢谢