lkml.org 
[lkml]   [2003]   [Dec]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectFile change notification
Hi everybody.

This is my first post to lkml, so please be patient with me

I have been wondering for some time why there is no decent file change
notification mechanism in linux. Is there some deep philosophical reason
for this, or is it just that nobody has found the time to implement it?
If it is the latter, I am willing to implement it as long there is a
chance to get this accepted into the mainstream kernel.

Is there already somebody working on this problem? I know a few efforts
that try to do something similar, but they all work by intercepting
every single system call that has to do with files, and they are thus
not very fast. See for example
<http://www.bangstate.com/software.html#changedfiles>
<http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/openxdsm/openxdsm/eventmodule/>


The dnotify mechanism is very limited since it requires a file handle,
it is not working for whole directory trees and it does not report much
useful information. For example to watch for changes in the /home tree
you would have to open every single directory in the tree, which would
probably not even work since it would require more than the maximum
number of file handles. If you have a directory with many files in it,
the only thing dnotify tells you is that something has changed in the
directory, so you have to rescan the whole directory to find out which
file has changed. Kind of defeats the purpose of change notification...

What I would like to have would be some way to watch for certain changes
anywhere in a whole tree or even the whole file system. This new
mechanism should have no measurable performance impact and should log
all information that is readily available. The amount of new code in
kernel space should be as small as possible. So complicated stuff like
pattern matching would have to happen in user space.

I wrote some experimental mechanism yesterday. Whenever a file is
accessed or changed, I write all easily available information to a ring
buffer which is presented to user space as a device. The information
that is easily available is the inode number of the file or directory
that has changed, the inode number of the directory in which the change
took place, and in most cases the name of the dentry of the file that
has changed.

Here is the struct I use for logging:

typedef struct
{
unsigned long event; /* the type of change. As of now, I use the same
constants as dnotify */
unsigned long file_ino; /* the inode of the file that has changed (if
available) */
unsigned long src_ino; /* the inode of the directory in which the
change took place (if available) */
unsigned long dst_ino; /* the inode of the destination directory.
This is only used when logging moves */
unsigned char name[DNAME_LEN]; /* the name of the dentry of the
changed file. This is simply truncated if it is too long. */
} inotify_info;

Information that is not easily available and therefore not logged
includes the full path(s) of the changed file/directory. If you want or
need that, you will have to look it up in user space.

Since I only log information that can be gathered at practically no
cost, the logging does not take any noticeable time in kernel space.

I attached a patch containing the code I wrote yesterday. This is very
preliminary and probably not bug-free. I would like to have feedback on
the general approach before I spend more time refining this.

best regards,

Rüdiger Klaehn


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