2015-09-07 60 views
1

一种可能的方式是,将给定的inode与该目录中的inode列表进行比较。 inode的列表可以预先确定或可以计算运行时间,两种方式都有自己的问题:在一个内核模块中,如何知道inode是否属于某个特定的目录?

  • 预定列表:列表可以在此操作过程中被改变,即文件可以添加或删除该目录。

  • 运行时间列表:如果该目录中文件太多,每次访问系统中的任何文件都会产生太多开销。

对此有任何有效的解决方案/办法?我试图通过比较文件路径,这真的是一个坏主意。

+0

你为什么要这么做?通常不鼓励内核模块与文件系统进行交互。 –

+0

@JohnKugelman,我只需要知道我的** foo **目录中的任何文件是否被不需要的进程访问。 'fanotify'也是一个很好的解决方案,但它不会递归地执行。 –

+0

为什么你想知道?为什么你的内核模块完全知道目录?参见[此LKML消息](http://lkml.iu.edu/hypermail/linux/kernel/0005.3/0061.html):“编写一个内核模块不像编码的用户模式程序时,您应该 从来不写一个模块需要读取或写入任何逻辑设备,内核是将I/O转换为逻辑I/O的内核,试图在内核 中执行逻辑I/O实际上是向后退出....有可能在内核中执行文件I/O,但这样做严重违反了标准惯例。“ –

回答

0

要么,如果你在内核模式还是在用户模式下做到这一点没有任何优势。要看到,如果一个inode确实是在某些目录中,您必须阅读该目录文件所在的目录中,通常作为一个线性表。这可能会导致您的进程阻止目录块存在,如果没有缓存,并且在那段时间内可以修改目录内容。只有在执行该操作时保持目录inode被阻止才有帮助,但这会给操作系统添加严重的性能限制。另一个问题是每个文件系统都可以自由地以自己的格式实现目录内容。在用户空间中,您可以获得统一的目录格式,但在内核模式下,您必须处理不同文件系统类型的不同方法。为什么你需要知道这一点?我无法想象可能需要这种情况。也许你可以重新设计你的目录内容的算法是不必要的。

顺便说一句,处理完整路径或搜索目录有模糊的竞争条件,可以处理你的系统堵塞好歹。如果在你的搜索过程中有人试图断开你正在搜索的inode,那么会发生什么?或者目录内容必须修改;或者某个其他进程正在使用namei()向上遍历您的目录;或向下。你有没有想过在所有这些可能性?

+0

如果您可以阅读下面的所有评论,您可能已经注意到,我正在这样做来保护应用程序特定的文件。有两种方法可以做到这一点,通过访问'path'或'inode'进行检查。是的,几乎无法确定'inode'是否属于某个目录,因此我将使用'path',因为与其他解决方案相比,这是做到这一点的唯一方法。 [这个答案](http://stackoverflow.com/a/28224286/2706918)可以很容易地获得绝对路径进行比较。 –

+0

unix/linux的设计原则是在用户平面实施策略。您是否考虑过在SeLinux方法的用户空间中进行此操作?如果你最终遵循这种方法,你将不得不通过回归测试到整个内核,因为根据规范,linux内核受到与unix sysv相同的竞争条件和问题的影响。由于'namei()'例程只是锁定_passing through_上的inode,因此与着名的书籍* Maurice J.Bach –

+0

......在UNIX操作系统的设计中出现的相同问题在1986年已经指出了很大的可能性设计准则是编写功能,而不是内核中的策略,可能内核中的大多数模块都依赖于这个原则。可能你最好改变你的设计,而不是依靠这个功能。用户空间中的任何内容都不依赖于了解inode编号。 –

相关问题