EC2 linux 实例上未引用的 inode

Question

我有一个 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

Answer 1

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

以下是对文件和 inode 之间关系的过于简单化的解释。文件本质上是文件系统中的一条记录，它为特定的 inode 分配一个名称（或多个名称）。打开的文件实际上是由 inode 引用的。当您删除一个文件时，您实际上是在删除名称和 inode 之间的链接，但是打开的文件还维护了打开的文件描述符和 inode 之间的链接。关闭文件会删除打开的文件描述符和 inode 之间的链接。在删除所有链接之前，文件系统不会回收 inode。

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

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

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