为什么 find -inum 会遍历整个文件系统树?

为什么 find -inum 会遍历整个文件系统树?

当我做一个简单的操作时,看到 find 迭代/遍历整个文件系统,让我感到惊讶

find -inum 12345

如果没有背景信息,在我看来应该有更简单的方法来告诉所有具有这个特定 inode 12345 (这只是一个占位符)的文件?

有没有更好的方法呢?不需要检查文件系统的所有目录结构,只需判断哪些文件名与索引节点相关?

更新

还有一个问题可以解决这个问题 快速查找哪些文件属于特定 inode 编号 但目的是找到更好(更快的方法)。

这个问题更直接的是要知道为什么会出现这样的问题?也许有一个与权限等相关的充分理由,这会试图故意让用户难以避免遍历目录结构来寻找索引节点的所有文件名。

尽管如此,任何文件系统都会遇到这样的问题,将所有文件名告诉 inode (至少是特权用户root) ,这似乎很奇怪

我最想回答这个问题(如果重要的话)的文件系统是 ext4。

答案1

非常简单的原因是,至少对于 ext2/ext3/ext4 类型的文件系统,文件名是通过目录条目数据存储在目录类型文件中。

这意味着来自类型目录的那些文件具有或多或少复杂的系统来存储文件名(目录内的文件)以及导致这些文件的数据的索引节点。

稍微简化了(ext3/4 使用哈希表增强功能来加速目录树遍历等...)它看起来像这样的列表:

## filenames ##    ## inode-numbers ##
filename1            0123
filename2            01242
anotherfilename      3313
yetanotherfilename   11233

本质上是文件名仅发生在与目录文件相关的数据内部,并且不存储在元数据中的任何位置文件系统存储对于/的索引节点。因此,获取与索引节点号相关的文件名的唯一方法是遍历所有目录文件的所有目录条目。

答案2

你写了:

当我执行一个简单的 find -inum 12345 时,令我惊讶的是发现 find 迭代/遍历整个文件系统

find根据定义,树是否从给定的一个或多个目录开始遍历,默认起始目录为..

find -inum 12345将从当前工作目录开始遍历整个目录树。它可能不会遍历整个文件系统,除非.碰巧包含文件系统安装点。

有更有效的方法可以找到具有给定索引节点号的所有文件 - fsdbdebugfsncheck在您链接到的答案中 - 但find必须进行树遍历,因为标准。请注意,如果您要查找的索引节点只有一个链接,您可以提供find选项-quit(如果支持)在第一个匹配后结束树遍历。

即使其他命令也并不总是很快,部分原因是它们必须查看整个文件系统而不仅仅是目录树,但它们会尽力利用可用的数据。基本问题是大多数 Unix 文件系统的结构。

  • 文件的索引节点中有很多信息,但“文件的名称或名称”和“包含该文件的目录或目录”并不在其中。
  • 大多数 Unix 文件系统上的目录结构非常简单:它只包含一个条目列表,每个条目都是一个(索引节点号,文件名)对。
  • 为了找到包含 inode 12345 的目录,以及这些目录引用它的名称,在大多数 Unix 文件系统上,这些命令必须搜索文件系统上每个目录的每个条目,直到找到所有匹配的条目。文件的 inode包含引用它的目录条目的数量,因此他们可以在找到那么多条目后立即停止搜索。
  • 相比之下,查找目录名称的效率要高得多,因为每个目录都包含其父目录的索引节点号,..因此只需在一个目录中搜索匹配的条目即可。 (有一个例外:文件系统的根目录有一个..条目指向同一目录。)

答案3

更简单的答案可能是类比。

想象一下在电话簿中搜索电话号码而不是姓名。

相关内容