lkml.org 
[lkml]   [2008]   [Dec]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH -v4 00/14] fsnotify, dnotify, and inotify
On Fri, Dec 12, 2008 at 4:51 PM, Eric Paris <eparis@redhat.com> 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
directory.
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 http://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00022.html
), and doesn't give me any tools to deal with the actual hard races or
path-maintenance problems.
--scott

--
( http://cscott.net/ )


\
 
 \ /
  Last update: 2008-12-19 00:39    [W:0.313 / U:0.772 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site