标签: inode

在linux 内核模块中(即在内核空间中工作),我有一个文件路径.

可以使用哪些函数来获取该文件的inode.具体来说,我需要让"inode*"指向文件的inode.

我对Linux有一般性的疑问.如果我创建一个fifo,是否会创建inode？管？插座？

只是想知道共享内存的关键是文件名还是 inode。

我有一个名为 .last 的文件，它只是一个指向名为 YYYYMMDDHHMMSS 的文件的硬链接。

一个目录看起来像这样：

20110101143000  
.last

.last 只是到 20110101143000 的硬链接。

一段时间后，创建了一个新文件

20110101143000  
20110622083000  
.last

然后我们删除 .last，并重新创建它以引用新文件。

我们的软件在这些更新期间持续运行，使用 MAP_SHARED 映射 .last 文件。处理完文件后，软件可能会将其缓存几分钟，而不是取消映射。在一台物理服务器上，有 12-24 个软件实例同时运行。不同的实例通常会同时映射同一个文件。我的问题是：

linux 是使用文件名来锁定共享内存，还是使用 inode？

鉴于这种情况：

1. proc A mmaps .last，并且不会取消映射
2. 写入新文件，删除 .last，创建新的 .last 以链接新文件
3. proc B 映射新的 .last，并且不会取消映射

如果 linux 使用 inode，那么 proc A 和 B 将看到映射到不同文件的不同内存块，这就是我们想要的。如果 linux 使用文件名，那么 A 和 B 都会看到映射到新文件的相同内存块。B 没问题，但是当分片块中的内存发生变化时，A 崩溃了。

有谁知道它实际上是如何工作的？我要测试，但如果结果是基于名称的，除非有人知道诀窍，否则我就完蛋了。

谢谢！

我正在使用Sun的JDK 1.6.0_26和NIO(使用Netty),在lsof中我看到数百个文件描述符anon_inode:

$ lsof -np 11225 | fgrep -w anon_inode
java    11225 nobody   57u     0000                0,9         0     1386 anon_inode
java    11225 nobody   61u     0000                0,9         0     1386 anon_inode
java    11225 nobody   65u     0000                0,9         0     1386 anon_inode
java    11225 nobody   69u     0000                0,9         0     1386 anon_inode
java    11225 nobody   73u     0000                0,9         0     1386 anon_inode
java    11225 nobody   77u     0000                0,9         0     1386 anon_inode
java    11225 nobody   81u     0000                0,9         0     1386 anon_inode
java    11225 nobody   86u     0000 …

inode 编号是否保证（例如通过标准）在重新启动、重新安装或什至在所有进程关闭然后再次打开后都相同？例如，它可以在打开文件时自动生成，而不是存储在文件系统上。应用程序可以依赖它吗？文件系统实现是否需要保证特定的语义？

如何通过只知道文件的inode来检索bash中的文件内容？

我想从 Linux Kernel v3.0.8 中检查文件的内容，只知道struct inode *. 我只需要读取这个 inode 指向的文件的开头，然后关闭并返回。我不关心文件名/挂载点等附加信息。事实上，文件可能没有名称（如已删除但仍打开）。是否可以？

我对这个inode号的定义感到惊讶:

inode是传统Unix风格文件系统(如UFS或ext3)上的数据结构.inode存储有关常规文件,目录或其他文件系统对象的基本信息.资源

因此,每个inode编号必须有一个逻辑顺序.你能直接从前面的数字中得出结论吗？

4214970 0 drwx------  102 user  staff   3.4K Feb  2 22:34 new
5728909 0 drwx------    3 user  staff   102B Mar 25 22:11 new_new
5415906 0 drwx------   15 user  staff   510B Mar 19 02:28 stdout_TEST

如果没有,由于数据结构,你可以知道什么样的事情？

某些解决方案可能适用于Windows,但我不熟悉Windows操作系统,因此这将是针对Linux的.

据我所知,Unix文件系统都具有inode的概念,这是文件系统元数据和"文件"的存储位置.因此,我想知道是否可以使用带有一些附加信息的inode号来跟踪重命名或移动的文件？

我建议做的是初始扫描,它将创建一个文件名/路径数据库,它所在的磁盘/驱动器,它们的inode号,最后是某种校验和(sha-1).

这将使系统能够使用inode编号快速检测文件是否被移动或重命名,然后它将跟进校验和以检查它是否实际上是相同的文件.

我可以看到这个方案可能存在的一些问题:

1. 可以修改文件然后移动/重命名,这将无法检测到它,因为校验和不匹配.
2. 一些(大多数？)应用程序在修改文件时会创建一个新的临时文件然后用当前文件切换它,因此即使文件最终未经修改,inode也无法匹配....
3. 需要存储它所在的设备/文件系统,因为每个文件系统上的inode对于该文件系统是唯一的.
4. 需要处理硬链接

我想知道我在这里忘记了还有其他问题吗？我希望能够使用inode快速跟踪哪些文件被移动或重命名,然后跟进校验和以确认它实际上是同一个文件.

我对在Linux文件系统中如何使用inode号有几个问题。这些问题可能是相关的，但为清楚起见，我将一一询问。

Q1：以EXT2 / 3为例，来自“ 第二个扩展文件系统的设计和实现 ”，我知道块组中有inode表，并且我知道inode会提供文件，但是如果文件太多但inode编号会怎样？还不够？我最好的猜测是，如果所有索引节点号都用完了，文件系统什么也不做。并且如果某些文件稍后被删除，其索引节点可能会被回收。

Q2：我在Linux服务器上运行“ df -i”，并且得到以下信息：

Filesystem            Inodes       IUsed   IFree      IUse% Mounted on    
    /dev/sda1          1313280    7853 1305427    1%     /
    devtmpfs                   0       0       0              -       /dev
    tmpfs                 525298       4  525294        1%    /dev/shm
    /dev/sda2              65808      50   65758       1%    /boot
    /dev/sda5            1313280     146 1313134    1%   /opt
    /dev/sda6             655776      37  655739      1%   /tmp
    /dev/sda7             655776    5219  650557    1%   /home
    /dev/sda8            1313280     840 1312440    1%  /var
    /dev/sda9             655776   36529  619247    6%  /usr
    /dev/sda10              6432      11    6421        1%  /crash
    /dev/sda12            135488      11  135477 …