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

发布于 2024-08-02 07:02:06 字数 1132 浏览 11 评论 0原文

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

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

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

我通过以下方式获得它们在 root 运行以下命令

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

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

原文

Why does /cdrom has the same inode -number than /sys/devices/platform/power in Ubuntu?

The following have the same inode number in my Ubuntu

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

I get them by running the following at root

find . -inum 12 2> /dev/null

Reply to Leffler's answer

I run

stat cdrom

I get

  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

What does this info tell you?

Reply to Leffler's edit

Often, you can dissect the device
number into a major and minor device
number which is what 'ls -l' prints
for a device.

This command ls -l cdrom gives me this

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

How can you see the major and minor device number from this?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

我的影子我的梦 2024-08-09 07:02:06

这些设备可能位于不同的文件系统上 - 文件系统和索引节点号的组合是唯一的。

如果您使用 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 ->媒体/光盘
如何从中看到主设备号和次设备号？

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

ls -l media/cdrom
ls -lL cdrom

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

The devices are probably on different file systems - and it is the combination of the file system and the inode number that is unique.

If you use the stat() system call, the relevant fields are the st_ino and st_dev (and st_rdev identifies special devices).

The question was extended - asking what information can be gleaned from:

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

There are many things that can be gleaned from this. The key ones are that this symbolic link is on the file system with device number (st_rdev) of 0x0801 (or 2049), and the inode number is 12. Often, you can dissect the device number into a major and minor device number which is what 'ls -l' prints for a device. There's a decent chance (but I have not formally verified this) that the major device number is 8 and the minor device is 1 (based on the hex representation 0x0801).

The question was extended a second time:

This command ls -l cdrom gives me this
lrwxrwxrwx 1 root root 11 2009-08-03 04:19 cdrom -> media/cdrom
How can you see the major and minor device number from this?

The short answer is "you can't". The output from one of these might be appropriately informative:

ls -l media/cdrom
ls -lL cdrom

The device shown in the previous question (the output from the stat command) has, I suggested, major device 8 and minor device 1. You'd find that by running 'ls -l' on the device that is mounted as the file system for '.'. You might use 'df .' to find the name of the mounted device - there are probably other mechanisms that would work too.

回复收藏 0 原文

乖乖 2024-08-09 07:02:06

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

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

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

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

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

除此之外，/media/BACKUP_1 可能是一个 VFAT32 文件系统，它是一个 DOS 文件系统。索引节点是一个 Unix 概念，因此 VFAT32 甚至没有索引节点，而且它们也是合成的。

事实上，许多现代 Unix 文件系统也没有 inode，它们将文件存储在 B⁺ 树或其他一些高度优化的数据结构中，并通过它们在树中的位置隐式地寻址它们。我知道 Reiser4 文件系统遇到了一些麻烦，因为在某些情况下它们根本没有合成 inode 编号，或者合成了非常大的 inode 编号，这再次破坏了一些工具。（一些愚蠢的工具实现需要执行类似于 find -inode 的操作，只是简单地构建一个从 0 到它们能找到的最高 inode 编号的数组，如果它们提供了一个非常大的索引节点号。）

An inode uniquely identifies a file on a filesystem. In your example, you are looking at three different filesystems: /, /media/BACKUP_1 (presumably an external VFAT32 drive or stick) and /sys.

These are three different filesystems; it is perfectly normal for the same inode number to be used on different filesystems. If inode numbers had to be unique across all filesystems, that would be a pretty harsh requirement, for several reasons:

there could only be 2^{sizeof(inode_t) × BITS_PER_BYTE} files in the entire world and
every computer on the entire planet would need to be connected to every other computer all the time so that they don't accidentally hand out the same number twice.

Just imagine this: you create a file on your external device. Then you detach it and attach it to a different computer, which also creates a file. How would computer A know which inode numbers are already used by computer B?

Also, in your case there is a different peculiarity: /sys is not a "real" filesystem, it is a virtual filesystem. It only exposes internal kernel datastructures as files and directories. And it doesn't even do this all the time, it only does this when you actually look at it – then, and only then do the files magically spring into existence. Therefore, its inode numbers are synthesized and don't really have any use at all – indeed, IIRC some virtual filesystems just set the inode number to 0 for every file, or at least they tried to until they realized that this broke all sorts of tools.

In addition to that, /media/BACKUP_1 is presumably a VFAT32 filesystem, which is a DOS filesystem. Inodes are a Unix concept, so VFAT32 doesn't even have inodes, and again they are synthesized.

Indeed, many modern Unix filesystems don't have inodes either, they store files in B⁺ trees or some other highly optimized data structure and address them implicitly through their position in the tree. I know that the Reiser4 filesystem had some trouble because in some cases they didn't synthesize inode numbers at all or synthesized very big inode numbers that again broke some tools. (Some stupid implementations of tools which needed to do things similar to find -inode simply built an array from 0 to the highest inode number they could find, which would then consume all available memory on the machine if they were presented with an extremely large inode number.)

回复收藏 0 原文