> > > As a result, when an event occures on a inode within the exported > > > directory by virtiofs, two events will be generated at the same time; a > > > local event (generated by the guest kernel) and a remote event (generated > > > by the host), thus the guest will receive duplicate events. > > > > > > To account for this issue we implemented two modes; one where local events > > > function as expected (when virtiofsd does not support the remote > > > inotify) and one where the local events are suppressed and only the > > > remote events originating from the host side are let through (when > > > virtiofsd supports the remote inotify). > > > > Dropping events from the local side would be weird. > > Avoiding duplicate events is not a good enough reason IMO > > compared to the problems this could cause. > > I am not convinced this is worth it. > > So what should be done? If we don't drop local events, then application > will see both local and remote events. And then we will have to build > this knowledge in API that an event can be either local or remote. > Application should be able to distinguish between these two and act > accordingly. That sounds like a lot. And I am not even sure if application > cares about local events in case of a remote shared filesystem. > I am not completely ruling out the S_NONOTIFY inode flag, but I am not yet convinced that it is needed. So what if applications get duplicate events? What's the worst thing that could happen? And once again, merging most of the duplicate events is pretty easy and fanotify does that already. > I have no experience with inotify/fanotify/fsnotify and what people > expect from inotify/fanotify API. So we are open to all the ideas > w.r.t what will be a good design to support this thing on remote > filesystems. Currently whole infrastructure seems to be written with > local filesystems in mind. > I have no control of what users expect from inotify/fanotify but I do know that some users' expectations are misaligned with how inotify/fanotify actually works. For example, some users may expect events not to be reordered, but there is no such guarantee. Some inotify users would expect to find a file with the filename in the event without realizing that this is a snapshot of a past filename, that may now not exist or be a completely different object. Those are some misconceptions that we tried to address with the fanotify FAN_REPORT_DFID_NAME APIs and hopefully we also documented the expectations better in the man page. The use of NFS file handles to identify objects in the FAN_REPORT_FID modes enables getting events also for already dead objects (without keeping the inode alive like inotify). I didn't want to complicate Ioannis in this early stage, but I think that FUSE fsnotify should be tied to LOOKUP_HANDLE. All FUSE remote objects should be described by file handles which is the same manner in which network protocols work and file handles should be used to describe objects in fsnotify FUSE events. But I am getting ahead of myself with a lot of hand waving.... Thanks, Amir.
