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.024 / U:0.472 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site