关于 Linux 中的索引节点 Inode，你需要知道的一切

发生在我的亲身经历，我还有很多 GB，但我的 Linux 系统却抱怨没有空间了。这是我开始了解索引节点 inode 的时候。

inode 简介

Inode 将系统上每个文件的元数据存储在通常位于分区开头附近的表状结构中。它们存储除文件名和数据之外的所有信息。

给定目录中的每个文件都是一个带有文件名和 inode 编号的条目。通过引用索引节点号从索引节点表中检索有关该文件的所有其他信息。

Inode 编号在分区级别是唯一的。每个分区都有自己的 inode 表。

如果 inode 用完了，即使给定分区上还有剩余空间，也无法创建新文件。

Linux 中的 inode 是什么？

inode（Index Node）译成中文就是索引节点。虽然历史上对此不太确定，但这是他们提出的最合乎逻辑、最好的猜测。它曾经写成I-node，但连字符随着时间的推移丢失了。

如linfo.org上所述：

inode是一种数据结构…… …… 它存储文件的所有信息，除了文件名和实际数据。

Inode 存储有关它引用的文件的元数据。此元数据包含有关所述文件的所有信息。

• 文件大小
• 访问权限
• 创建时间
• 修改时间
• 数据在磁盘的位置
• 其他信息

每个使用的 inode 引用一个文件。每个文件都有一个 inode。目录、字符文件和块设备都是文件。它们每个都有一个 inode。

对于目录中的每个文件，都有一个条目，其中包含文件名和与之关联的索引节点号。

Inode 在分区级别是唯一的。如果两个文件位于不同的分区上，则它们可以具有相同的 inode 编号。Inodes 信息存储在每个分区的战略部分的类似表的结构中，通常在开头附近找到。

如何在 Linux 中查看 inode？

您可以使用以下命令轻松列出 inode 编号：

ls -i

下面的图片显示了我的根目录以及相应的 inode 编号。

每个文件系统拥有的 inode 数量是在创建文件系统时决定的。对于大多数用户来说，默认的 inode 数量已经足够了。

创建文件系统时的默认设置是每 2K 字节空间创建 1 个索引节点。这为大多数系统提供了大量 inode。在用完 inode 之前，您很可能会用完空间。如果需要，您可以在创建文件系统时指定要创建多少 inode。

如果您用完 inode，您将无法创建新文件。您的系统也将无法这样做。大多数用户不会遇到这种情况，但这是可能的。

例如，邮件服务器会存储大量非常小的文件。许多这些文件将小于 2K 字节。它也有望不断增长。因此，邮件服务器有可能在空间用完之前用完 inode。

一些文件系统，如Btrfs、JFS、 XFS 已经实现了动态索引节点。如果需要，他们可以增加可用的 inode 数量。

索引节点是如何工作的？

创建新文件时，会为其分配一个 inode 编号和文件名。inode 编号是该文件系统中的唯一编号。名称和 inode 编号都作为条目存储在目录中。

当我运行ls 命令“ ls -li / ”时，文件名和 inode 编号是存储在目录/中的内容。使用 inode 编号从 inode 表中检索剩余信息用户、组、文件权限、大小等。

您可以在 Linux 中使用 df 命令列出每个文件系统的 inode 信息：

┌──(linuxmi㉿linuxmi)-[~]
└─$ df -hi

在 Linux 中列出 inode 信息

索引节点和软/硬链接

软链接或符号链接是 Linux 的一个众所周知的功能。但是，当您在 Linux 中创建符号链接时，Inode 会发生什么情况？在下一张图片中，我有一个名为“ dir1 ”的目录，一个名为“ file1 ”的文件，在“ dir1 ”中我有一个名为“ slink1 ”的软链接，它指向“ ../file1 ”

┌──(linuxmi㉿linuxmi)-[~/linuxmi]
└─$ tree
.
├── dir1
│   └── slink1 -> ../file1
└── file1

1 directory, 2 files

现在我可以递归列出并显示 inode 信息。

┌──(linuxmi㉿linuxmi)-[~/linuxmi]
└─$ ls -liR
.:
总计 4
13247036 drwxr-xr-x 2 linuxmi linuxmi 4096  2月 3日 20:19 dir1
13119533 -rw-r--r-- 2 linuxmi linuxmi    0  1月 8日 14:28 file1

./dir1:
总计 0
13247041 lrwxrwxrwx 1 linuxmi linuxmi 8  2月 3日 20:19 slink1 -> ../file1

正如预期的那样，dir1 和 file1 具有不同的 inode 编号。而且软链接也是如此。创建软链接时，您创建了一个新文件。在其元数据中，它指向目标。对于您创建的每个软链接，您都使用一个 inode。

使用ln 命令在 dir1 中创建硬链接后：

┌──(linuxmi㉿linuxmi)-[~/linuxmi/dir1]
└─$ ln ../file1 hlink1

inode 编号列表为我提供了以下信息：

┌──(linuxmi㉿linuxmi)-[~/linuxmi]
└─$ ls -liR
.:
总计 4
13247036 drwxr-xr-x 2 linuxmi linuxmi 4096  2月 3日 20:23 dir1
13119533 -rw-r--r-- 2 linuxmi linuxmi    0  1月 8日 14:28 file1

./dir1:
总计 0
13119533 -rw-r--r-- 2 linuxmi linuxmi 0  1月 8日 14:28 hlink1
13247041 lrwxrwxrwx 1 linuxmi linuxmi 8  2月 3日 20:19 slink1 -> ../file1

您可以看到“ file1”和“ hlink1 ”具有相同的 inode 编号。说实话，由于索引节点，硬链接成为可能。硬链接不会创建新文件。它只是为相同的数据提供了一个新名称。

在旧版本的 Linux 中，可以硬链接目录。甚至可以让给定的目录成为它自己的父目录。由于 inode 实现，这成为可能。这现在受到限制，以防止用户创建非常混乱的目录结构。

inode 的其他含义

inode 的工作方式也是不可能在不同文件系统之间创建硬链接的原因。允许这样的任务将打开 inode 编号冲突的可能性。另一方面，可以跨不同的文件系统创建软链接。

因为硬链接和原文件有相同的inode号，你可以删除原文件，数据仍然可以通过硬链接访问。在这种情况下，您所做的只是删除指向该 inode 编号的名称之一。链接到此 inode 编号的数据将保持可用，直到删除与其关联的所有名称。

索引节点也是 Linux 系统无需重启即可更新的重要原因。这是因为一个进程可以使用库文件，而另一个进程可以用新版本替换该文件。因此，为新文件创建一个新的 inode。已经运行的进程将继续使用旧文件，而每次对其进行新调用都会导致使用新版本。

inode 附带的另一个有趣的特性是能够将数据存储在 inode 本身中。这称为内联。这种存储方法具有节省空间的优点，因为不需要数据块。它还通过避免更多的磁盘访问来获取数据来增加查找时间。

某些文件系统（如 ext4）有一个名为 inline_data 的选项。启用后，它允许操作系统以这种方式存储数据。由于大小限制，内联仅适用于非常小的文件。ext2 及以后的版本经常会这样存储软链接信息。也就是说，如果大小不超过 60 字节。

结论

Inode 不是您直接与之交互的东西，但它们扮演着重要的角色。如果一个分区要包含许多非常小的文件，比如邮件服务器，了解它们是什么以及它们如何工作可以为您避免很多问题。