On Wed, 2009-09-16 at 13:56 +0100, Jamie Lokier wrote: > Alan Cox wrote: > > > You can't rely on the name being non-racy, but you _can_ reliably > > > invalidate application-level caches from the sequence of events > > > including file writes, creates, renames, links, unlinks, mounts. And > > > revalidate such caches by the absence of pending events. > > > > You can't however create the caches reliably because you've no idea if > > you are referencing the right object in the first place - which is why > > you want a handle in these cases. I see fanotify as a handle producing > > addition to inotify, not as a replacement (plus some other bits around > > open blocking for HSM etc) > > There are two sets of events getting mixed up here. Inode events - > reads, writes, truncates, chmods; and directory events - renames, > links, creates, unlinks. My understanding of you argument is that fanotify does not yet provide all inotify events, namely those of directories operations and thus is not suitable to wholesale replace everything inotify can do. I've already said that working towards that goal is something I plan to pursue, but for now, you still have inotify. The mlocate/updatedb people ask me about fanotify and it's on the todo list to allow global reception of of such events. The fd you get would be of the dir where the event happened. They didn't care, and I haven't decided if we would provide the path component like inotify does. Most users are perfectly happy to stat everything in the dir. It's hopefully feasible, but it's going to take some fsnotify hook movements and possibly so arguments with Al to get the information I want where I want it. But there is nothing about the interface that precludes it and it has been discussed and considered. Am I still missing it? -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
