2

为什么 /cdrom 的 inode -number 与/sys/devices/platform/powerUbuntu 中的相同？

以下在我的 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

你怎么能从中看到主要和次要设备号？

4

4 回答 4

6

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

如果使用stat()系统调用，则相关字段为st_inoand 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

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

于 2009-08-17T19:18:47.393 回答
2

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

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

  • 只能有 2 sizeof(inode_t) × BITS_PER_BYTE文件在整个世界和
  • 整个星球上的每台计算机都需要一直与其他计算机连接，这样他们就不会意外地两次分发相同的号码。

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

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

除此之外，/media/BACKUP_1大概是一个 VFAT32 文件系统，它是一个 DOS 文件系统。inode是 Unix 的概念，所以 VFAT32 甚至没有inode，它们又是合成的。

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

于 2009-08-17T20:22:29.573 回答
1

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

于 2009-08-17T20:17:06.573 回答
0

要验证 Hex 和 Dec 数字，请使用：

$ echo "obase=16; 2049"|bc 
801
于 2009-08-18T05:22:23.980 回答