Messages in this thread | | | Date | Wed, 31 Dec 2003 17:42:45 +0100 | From | Rüdiger Klaehn <> | Subject | File 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
| |