☰

EC2 Linux 实例上未引用的 inode

tag-icon • tag-icon disk-usage inode ec2
EC2 Linux 实例上未引用的 inode

我有一个 Amazon EC2 实例，将其用作 NFS 文件服务器。它使用 5x1TB 卷 RAID0 阵列。该系统是 I/O 密集型的，文件始终通过 NFS 共享写入/复制/删除。我经常注意到已用磁盘空间和可用空间之间存在很大差异。 （我在系统空闲且没有文件写入文件共享/系统时进行检查）。我对此的唯一“修复”是关闭实例并重新启动它（重新启动不起作用，只是挂起机器）。当它重新启动时，它会运行fsck，我可以在系统日志中看到（许多）“未引用的”索引节点正在被清理（这不是整个日志）：

   25.110924] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291727
[   25.114687] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291723
[   25.118610] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291703
[   25.135184] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291722
[   25.140005] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291725
[   25.144013] EXT4-fs (dm-1): ext4_orphan_cleanup: deleting unreferenced inode 122291705
[   25.148008] EXT4-fs (dm-1): 735 orphan inodes deleted
[   25.150286] EXT4-fs (dm-1): recovery complete
[   26.126887] EXT4-fs (dm-1): mounted filesystem with ordered data mode. Opts: (null)
[  OK  ]

我在网上找不到任何解决方案。有谁知道造成这种情况的原因或如何预防？或者也许可以在不卸载驱动器的情况下修复它？

更多信息：

版本信息：

Linux version 3.10.42-52.145.amzn1.x86_64 (mockbuild@gobi-build-64003) (gcc version 4.8.2 20131212 (Red Hat 4.8.2-7) (GCC) ) #1 SMP Tue Jun 10 23:46:43 UTC 2014

RAID0阵列挂载/etc/fstab如下：

/dev/vg0/data /data ext4 defaults,auto,noatime,noexec 0 0

/etc/mdadm.conf：

DEVICE /dev/xvdk /dev/xvdj /dev/xvdi /dev/xvdh /dev/xvdg
ARRAY /dev/md0 metadata=1.2 name=ip-172-31-10-215:0 UUID=4c4fb472:e0540788:69a83d01:a75a8a3e

/etc/导出：

/data *(rw,sync)

客户端挂载NFS共享如下：

x.x.x.x:/data  /mnt/fileserver nfs defaults 0  0

答案1

您描述的行为可能是由于应用程序保持文件打开，即使文件已被删除。如果一个应用程序打开了一个文件（例如tail），而另一个应用程序出现并删除了该文件（例如rm），则第一个应用程序将继续保留对该文件的引用，直到该应用程序关闭该文件。此时，文件系统将识别出该文件已被删除且未被任何应用程序打开，并且它将清除引用。

这是对文件和索引节点如何关联的过于简单的解释。文件本质上是文件系统中的一条记录，它为特定的 inode 分配一个或多个名称。打开的文件实际上是通过inode来引用的。当你删除一个文件时，你实际上删除了文件名和索引节点之间的链接，但是打开的文件也会维护打开的文件描述符和索引节点之间的链接。关闭文件会删除打开的文件描述符和索引节点之间的链接。在删除所有链接之前，文件系统不会回收索引节点。

当您查看文件系统报告的可用空间时，它会告诉您与当前标记为已使用的所有 inode 关联的空间。当您查看所有目录并总结每个文件/目录使用的文件空间时，如果文件已被删除但仍处于打开状态，则文件空间可能会更少。您的目录扫描不会看到已删除名称链接的文件所使用的空间。

当您硬关闭系统时，您不会给应用程序关闭其文件的机会。如果没有这个机会，文件系统就没有机会回收已删除文件的打开文件描述符所使用的索引节点。当系统启动时，文件系统会看到这些 inode，但没有任何东西指向它们。这些被称为“孤立的索引节点”，文件系统会让您知道它正在删除文件引用。

您可以使用一种工具来查找具有打开文件描述符的进程lsof。如果您在进程上运行此命令，它将显示该进程的所有打开的文件描述符。删除的文件通常会显示为(deleted)，具体取决于版本。

相关内容