了解 Ubuntu 中不同对象的相同 inode 编号答案

【问题标题】：To understand the same inode numbers for different objects in Ubuntu了解 Ubuntu 中不同对象的相同 inode 编号
【发布时间】：2010-11-20 08:43:53
【问题描述】：

为什么 /cdrom 在 Ubuntu 中的 inode 编号与 /sys/devices/platform/power 相同？

以下在我的 Ubuntu 中具有相同的 inode 编号

./media/BACKUP_1/MISC
./cdrom
./sys/devices/platform/power

我通过在根目录下运行以下命令来获取它们

find . -inum 12 2> /dev/null

回复莱弗勒的回答

我跑

stat cdrom

我明白了

  File: `cdrom' -> `media/cdrom'
  Size: 11              Blocks: 0          IO Block: 4096   symbolic link
Device: 801h/2049d      Inode: 12          Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2009-08-03 04:25:35.000000000 +0300
Modify: 2009-08-03 04:19:05.000000000 +0300
Change: 2009-08-03 04:19:05.000000000 +0300

这些信息告诉你什么？

回复莱弗勒的编辑

通常，您可以剖析设备编号为主要和次要设备 'ls -l' 打印的数字用于设备。

这个命令ls -l cdrom 给了我这个

lrwxrwxrwx 1 root root 11 2009-08-03 04:19 cdrom -> media/cdrom

如何从中看出主要和次要设备号？

【问题讨论】：

标签： ubuntu inode

【解决方案1】：

设备可能位于不同的文件系统上 - 文件系统和 inode 编号的组合是唯一的。

如果使用stat()系统调用，相关字段为st_ino和st_dev（而st_rdev标识特殊设备）。

问题已扩展 - 询问可以从中收集哪些信息：

  File: `cdrom' -> `media/cdrom'
  Size: 11              Blocks: 0          IO Block: 4096   symbolic link
Device: 801h/2049d      Inode: 12          Links: 1

从中可以收集到很多东西。关键是这个符号链接在设备号（st_rdev）为 0x0801（或 2049）的文件系统上，inode 号为 12。通常，您可以将设备号分解为主要和次要设备号这是 'ls -l' 为设备打印的内容。很有可能（但我还没有正式验证这一点）主要设备号是 8，次要设备号是 1（基于十六进制表示 0x0801）。

第二次延长问题：

这个命令ls -l cdrom 给了我这个
lrwxrwxrwx 1 root root 11 2009-08-03 04:19 cdrom -> media/cdrom
如何从中看出主要和次要设备号？

简短的回答是“你不能”。其中之一的输出可能会提供适当的信息：

ls -l media/cdrom
ls -lL cdrom

我建议上一个问题中显示的设备（stat 命令的输出）具有主要设备 8 和次要设备 1。您可以通过在设备上运行“ls -l”来发现挂载为“.”的文件系统。您可以使用“df .”来查找已安装设备的名称 - 可能还有其他机制也可以使用。

【讨论】：

请参阅我关于命令ls -l 的问题中的第二个编辑。

【解决方案2】：

inode 唯一标识文件系统上的文件。在您的示例中，您正在查看三个不同文件系统：/、/media/BACKUP_1（可能是外部 VFAT32 驱动器或记忆棒）和 /sys。

这是三个不同的文件系统；在不同的文件系统上使用相同的 inode 号是完全正常的。如果 inode 编号在所有文件系统中必须是唯一的，那将是一个非常苛刻的要求，原因如下：

全世界只能有2个^{sizeof(inode_t) × BITS_PER_BYTE}个文件
整个星球上的每台计算机都需要始终与其他计算机连接，以免它们意外地两次分配相同的号码。

想象一下：您在外部设备上创建了一个文件。然后将其分离并将其附加到另一台计算机，这也会创建一个文件。计算机 A 如何知道计算机 B 已经使用了哪些 inode 编号？

此外，在您的情况下，还有一个不同的特性：/sys 不是“真实”文件系统，它是虚拟文件系统。它仅将内部内核数据结构公开为文件和目录。它甚至不会一直这样做，它只会在你真正看到它时才会这样做——然后，只有这样，文件才会神奇地出现。因此，它的 inode 编号是合成的，根本没有任何用处 - 事实上，IIRC 一些虚拟文件系统只是将 every 文件的 inode 编号设置为 0，或者至少他们试图直到他们意识到这会破坏各种工具。

除此之外，/media/BACKUP_1 大概是一个 VFAT32 文件系统，它是一个 DOS 文件系统。索引节点是一个 Unix 概念，因此 VFAT32 甚至没有索引节点，它们再次被合成。

确实，许多现代 Unix 文件系统也没有 inode，它们将文件存储在 B⁺ 树或其他一些高度优化的数据结构中，并通过它们在树中的位置隐式处理它们。我知道 Reiser4 文件系统有一些问题，因为在某些情况下，它们根本没有合成 inode 编号或合成非常大的 inode 编号，这再次破坏了某些工具。（一些愚蠢的工具实现需要做类似于find -inode 的事情，只是简单地构建了一个从 0 到他们能找到的最高 inode 编号的数组，然后如果它们出现一个非常大的 inode，它将消耗机器上的所有可用内存号。）

【讨论】：

很好的答案！ - 供参考，1 个字节为 8 位。
一个字节是最小的可寻址内存单元。在某些计算机上它是 8 位，在某些计算机上是 6、7、9 或 12。有些甚至可以在引导期间选择可变字节大小，在某些计算机上甚至可以按指令选择，有些甚至没有字节。（我知道有一些 ISO 规范将 Byte 定义为 8 位，但这仅适用于 in 该规范。）
有一个 Cray，C 编译器为其定义了 sizeof(char) == sizeof(int) == sizeof(long) 和 CHAR_BITS == 32。在那台机器上，一个字节是 32 位的。
有趣。在那种情况下，我实际上会争辩说机器根本没有字节，因为对我来说，一个字节意味着一个比一个词小的单位。但这取决于您如何定义“字节”和“单词”，我不会尝试这样做:-)

【解决方案3】：

/sys/ 是一个独立的文件系统，名为sysfs。 Inode 编号仅在特定文件系统中是唯一的，而不是在全局文件树中。

【讨论】：

【解决方案4】：

要验证十六进制和十进制数字，请使用：

$ echo "obase=16; 2049"|bc 
801

【讨论】：