[lkml]   [2008]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC PATCH -v4 00/14] fsnotify, dnotify, and inotify
    On Fri, Dec 12, 2008 at 4:51 PM, Eric Paris <> wrote:
    > The following series implements a new generic in kernel filesystem
    > notification system, fsnotify. On top of fsnotify I reimplement dnotify and
    > inotify. I have not finished with the change from inotify although I think
    > inotify_user should be completed. In kernel inotify users (aka audit) still
    > (until I get positive feedback) relay on the old inotify backend. This can be
    > 'easily' fixed.
    > All of this is in preperation for fanotify and using fanotify as an on access
    > file scanner. So you better know it's coming.
    > Why is this useful? Because I actually shrank the struct inode. That's
    > right, my code is smaller and faster. Eat that.

    As a desktop-search-and-indexing developer, it doesn't seem like
    fanotify is going to give me anything I want. The inotify/dnotify
    restructuring to fsnotify seems reasonable, but not exciting (to me).

    From a desktop search perspective, my wishlist reads like this:
    1) An 'autoadd' option added to inotify directory watches, so that
    newly-created subdirectories get atomically added to the watch. That
    would prevent missed IN_MOVED_FROM and IN_MOVED_TO in a newly created
    2) A reasonable interface to map inode #s to "the current path to
    this inode" -- or failing that, an iopen or ilink syscall. This would
    allow the search index to maintain inode #s instead of path names for
    files, which saves a lot of IN_MOVE processing and races (especially
    for directory moves, which require recursive path renaming).
    3) Dream case: in-kernel dirty bits. I don't *really* want to know
    all the details; I just want to know which inotify watches are dirty,
    so I can rescan them. To avoid races, the query should return a dirty
    watch and atomically clear its dirty flag, so that if it is updated
    again during my indexing, I'd be told to scan it again.

    From the indexing perspective, dealing with a sequence of operations like:
    1) mkdir -p abc/def
    2) echo "foo" > abc/def/ghi
    3) mv abc xyz
    4) mv xyz/def/ghi jkl
    is entirely too much "fun". Depending on the races between kernel and
    user space, I might get only:
    CREATE abc
    IN_MOVED_TO jkl
    and if I do get my watches put in place after step (1) I've still got
    to deal with a recursive rename in step (3), the possibility of
    getting notification of (2) after the rename in (3) (so abc/def/ghi no
    longer exists), and other delights.

    As far as I can tell, fanotify only helps with the 'recursive watch'
    problem (which could be solved with 'autoadd' or just using the
    algorithm in
    ), and doesn't give me any tools to deal with the actual hard races or
    path-maintenance problems.

    ( )

     \ /
      Last update: 2008-12-19 00:39    [W:0.024 / U:2.148 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site