Messages in this thread | | | Subject | Re: Issues with using fanotify for a filesystem indexer | From | Alexander Larsson <> | Date | Fri, 27 Mar 2009 14:47:03 +0100 |
| |
On Fri, 2009-03-27 at 13:02 +0000, Al Viro wrote: > On Fri, Mar 27, 2009 at 01:47:23PM +0100, Alexander Larsson wrote: > > > In order to write an app using the fanotify API satisfying the above > > needs we would need the following events: > > * the event queue overflowed, (you need to reindex everything) > > * An inode was linked into the filesystem (creat, O_CREAT, > > mkdir, link, symlink, etc) > > * An inode was unlinked (unlink, rmdir, rename replaced existing file) > > * An inode was moved in the filesystem (rename) > > Erm... Just how would you represent and *order* the events? Note that > "serialize all directory operations on given fs" is a non-starter...
This particular usecase doesn't really require a specific order for the events. Its enough to know that something changed in a directory, or a subtree. I can't think of an event reordering that would cause us to not eventually reindex the files was affected by a change.
Note, I don't think its possible to track renames precisely so that we know that a previosly indexed file is in another place now, but rather that if we move a directory from a to b we now need to fully reindex both the a and b subtrees.
However, the order might be important for other usecases, I can't really tell. Is it possible to give any kind of guarantee for the event order?
As for representation, I guess there are two issues here, how the event looks in the kernel side event queue and how it looks to userspace. I'm no kernel developer, but i guess a rename could be something liks
struct path *old_dir; char *old_name struct path *new_dir; char *new_name
and the userspace side could be:
int old_dir_fd char *old_name int new_dir_fd char *new_name
| |