From: Brian F. <bf...@re...> - 2014-03-18 12:05:41
|
On Tue, Mar 18, 2014 at 10:39:27AM +0100, Stef Bon wrote: > 2014-03-17 23:20 GMT+01:00 Brian Foster <bf...@re...>: > > On Mon, Mar 17, 2014 at 10:02:45PM +0100, Stef Bon wrote: > > > > > Ok, so you are attempting to funnel it up to the fuse mount. This is > > what I was getting at initially. > > > > Without knowing much at all about fsnotify internals, I suspect the > > problem is you can effectively only generate events for objects that > > already exist with respect to the fuse mount. E.g., digging into that > > fuse_notify_delete() path eventually calls d_delete(), which itself has > > an fsnotify_nameremove() call. The create event is probably triggered > > through the create codepath. For example, if a user went and created > > /mnt/myfile (on the fuse mount instead of /tmp/myfile), does the > > original watchpoint show an event? > > > > Aha I did not find that d_delete call. That needs testing, notifying a > delete should already trigger fsnotify! Great! > Note that we are still assuming the fuse inode exists. If you experiment, you'll probably want to make sure to see what happens if you do or do not access the inode through the fuse mount before testing the delete notification. > >> To make this work I have some idea's: > >> > >> a. make the kernel do a lookup when the fuse fs reports a new entry. > >> When this reports a positive result, this will also trigger the > >> original fsnotify watch (and thus also the userspace process which has > >> set this watch) > >> > > > > Are you sure the lookup in this instance is a trigger for fsnotify? As > > far as the top mount is concerned, I think it's just looking up a file > > that might have always existed. E.g., you'd want the same "create" event > > to propagate to the original watch. > > No I'm not sure. You're right about propagating the "create" event. > > > > >> b. make fsnotify report a "fake" new entry and leave it to the > >> userspace process what to do with it. This requires an extra flag. > >> Here it's required that the fuse module in the kernel reports back to > >> fsnotify watch. > >> > > > > I suppose you could dig further into the fsnotify code and see if > > there's a point where you could cleanly fake events in response to a > > notification from your fuse fs. > > > > Perhaps you could use that to extend on idea a. For example, check out > > some of the existing fsnotify_create() calls for reference. Add a new > > fuse notification with enough information to invoke fsnotify_create() on > > the top-level parent inode with the filename, etc. and see what > > happens... If you need the new inode, queue a lookup in response to the > > notification and invoke fsnotify_create() in the completion handler when > > you have an inode. This is some major hand waving, as that would > > probably require more thought/experiments. > > > > Yes that's the way to go. I have to dig into the code cause a > completion handler does not ring any bell for me. It looks like async > io. I'll see. Where do I have to program "queue a lookup". > I was just referring to the async request mechanism in the fuse driver as opposed to the sync mechanism. The former will require setting a completion handler as opposed to waiting for the request to complete in the caller. The idea here is that the fuse fs sends a new notification (fuse_notify_*()) and then the kernel turns around and sends a lookup request (if necessary) back to the fuse fs in the notify function. It might not be safe to do that synchronously..? You could experiment with it either way. ;) Brian > Thanks a lot, > > Stef Bon |