lkml.org 
[lkml]   [2004]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: File change notification (enhanced dnotify)
Horst von Brand wrote:
> =?ISO-8859-1?Q?R=FCdiger_Klaehn?= <rudi@gamemakers.de> said:
>
>>Horst von Brand wrote:
>>
>>>=?ISO-8859-1?Q?R=FCdiger_Klaehn?= <rudi@gamemakers.de> said:
>>>
>>>>I am working on a mechanism to let programs watch for file system
>>>>changes in large directory trees or on the whole system. Since my last
>>>>post in january I have been trying various approaches.
>
>
>>>How do you propose to handle the fact that there are changes to _files_,
>>>which happen to be pointed to by entries in directories? There is no
>>>"change in the directory tree" in Unix...
>
>
>>Of course it is files that change. But as you say each file is pointed
>>to by one or more dentry, so I use the dentry hierarchy to propagate the
>>information about the change. Just like the old dnotify.
>
>
> dentries just keep the path travelled by hard links to get to the file in
> memory for fast future access. So if you have, say:
>
> dir1 dir2
> | |
> . .
> . .
> . .
> \ /
> somefile
>
> and you referenced somefile by the path through dir1, if you monitor dir2
> you won't notice the change. There is no on-disk data to trace back through
> all the directories that reference the file, and reading all of the
> filesystem's metadata to find this out is ludicrous (ever seen fsck(8)
> taking an hour or so to make much the same?).

I am aware of that. As I mentioned, this approach does not work with
hard links, just like the original dnotify.

From the current "Documentation/dnotify.txt":
"In order to make the impact on the file system code as small as
possible, the problem of hard links to files has been ignored."

There would be some ways to solve this for hard links. But I don't think
that it would be worth it since it would involve a big performance
overhead for little gain.

Note that if you watch for changes in the root of a file system, you
will get notified exactly once for each file change in the file system
regardless of hard links.

In your example if you have one file which can be accessed via two
different paths "/dir1/somefile" and "/dir2/somefile" and you watch "/"
you would get notified for "/dir1/somefile" or "/dir2/somefile"
depending on how the changing program accesses the file.

Figuring out that "/dir1/somefile" and "/dir2/somefile" refer to the
same file should IMHO be done in userspace. If inode numbers were unique
and persistent on all file systems it might be possible to do this
efficiently in kernel space, but unfortunately this is not the case.

My original approach assumed that inode numbers were unique, and it
would have worked with hard links. But I think it is much more important
to have a mechanism that works for all file systems than to solve the
problem of hard links.

best regards,

Rüdiger

By the way: I just made a small website for my enhanced dnotify
mechanism. I will post my latest code there. It can be found at
<http://www.lambda-computing.com/~rudi/dnotify/>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:01    [W:0.133 / U:0.012 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site