On Wed, May 22, 2024 at 12:09 AM Jonathan Gilbert <logic@xxxxxxxxxx> wrote: > > On Tue, May 21, 2024 at 12:13 PM Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > Note that you will be combining the *current* directory path with the *past* > > filename, so you may get a path that never existed in reality, but as you wrote > > fanotify is not meant for keeping historical records of the filesystem > > namespace. > > And, in practice, this is almost certainly an edge case, because the > vast majority of user-driven activity will be on a time scale such > that the directory path hasn't had a chance to change since the file > event was generated, I think? It's more a, "You can't technically > guarantee 100% consistency", than a, "You should expect consistency > errors regularly," sort of thing? > I guess so, but I would not call this "consistency errors", because fanotify does not claim to report a "consistent" state or a snapshot, although it could be used to construct an "eventual consistent" state by examining the information in the events. - You should expect out of order events. - You should expect that the object information in the event that is described with dfid+name+fid may not exist with the same description at the time that the event is reported. > > > Are FAN_MOVED_FROM and FAN_MOVED_TO guaranteed to be emitted > > > atomically, or is there a possibility they could be split up by other > > > events? If so, could there be multiple overlapping > > > FAN_MOVED_FROM/FAN_MOVED_TO pairs under the right circumstances?? > > > > You are looking for FAN_RENAME, the new event that combines > > information from FAN_MOVED_FROM/FAN_MOVED_TO. > > Ah, excellent, this is in fact exactly what I needed. > > > > One other thing I'm seeing is that in enumerating the mount table in > > > order to mark things, I find multiple entries with the same fsid. > > > These seem to be cases where an item _inside another mount_ has been > > > used as the device for a mount. One example is /boot/grub, which is > > > mounted from /boot/efi/grub, where /boot/efi is itself mounted from a > > > physical device. > > > > Yes, this is called a bind mount, which can be generated using > > mount --bind /boot/efi/grub /boot/grub > > Huh, okay. I did some reading about this, and it seems that regardless > of the order in which things are done, quite simply it is always > possible for the same underlying filesystem to be mounted in multiple > places. When this happens, there's no way to tell which mount changes > were made through, but also, it isn't relevant because the same change > is visible through all such overlapping mounts simultaneously. So, > depending on the exact semantics I need, I need to either decide which > mount I'm going to pick as being the most meaningful for the event, or > alternately figure out *all* of the mounts to which the event applies. > > > > When enumerating the mounts, both of these return the > > > same fsid from fstatfs. There is at least one other with such a > > > collision, though it does not appear in fstab. Both the root > > > filesystem / and a filesystem mounted at > > > /var/snap/firefox/common/host-unspell return the same fsid. Does this > > > mean that there is simply a category of event that cannot be > > > guaranteed to return the correct path, because the only identifying > > > information, the fsid, isn't guaranteed to be unique? Or is there a > > > way to resolve this? > > > > That depends on how you are setting up your watches. > > Are you setting up FAN_MARK_FILESYSTEM watches on all > > mounted filesystem? > > That is the intent, yep. > > > Note that not all filesystems support NFS export file handles, > > so not all filesystem support being watched with FAN_REPORT_FID and > > FAN_MARK_FILESYSTEM. > > Good to know. My initial use case for the code is on my own personal > machine, which is a pretty much stock Ubuntu 24.04 LTS system with the > default ZFS layout. In my testing thus far, it looks like the kinds of > events I'm looking for are in fact captured. > It's good to know that someone is testing fanotify on ZFS ;-) > > If, for example you care about reconstructing changing over certain > > paths (e.g. /home), you can keep an open mount_fd of that path when you > > start watching it and keep it in a hash table with fsid as the key > > (that is how fsnotifywatch does it [1]) and then use that mount_fd whenever > > you want to decode the path from a parent file handle. > > Yeah, my starting point for development was the fatrace source code > which also does this. > Cool. I wasn't aware that fatrace has adopted FAN_REPORT_FID a long time before I added support to inotify-tools :) > > If /home is a bind mount from, say, /data/home/ and you are watching > > both /home and /data, you will need to figure out that they are the same > > underlying fs and use a mount_fd of /data. > > My current plan is to discard any mounts which specify a root that is > a subpath of another mount, and in the case of multiple mounts of the > same root, pick one to move forward with (with hints from > configuration) and only mark that one. > You can also use open_by_handle() to determine if one mount is a subtree of another. if you have two fds and two different fhandles from the root of two mounts of the same fsid, only one of these commands will result in an fd with non empty path: fd2inmount1 = open_by_handle_at(mount1_fd, fhandle2, O_PATH); fd1inmount2 = open_by_handle_at(mount2_fd, fhandle1, O_PATH); So you can throw away subtree mounts of the same fsid keeping only one mount_fd per fsid as you traverse the mounts. > This is starting to feel like all the bits are coming together. Thanks > so much for your insight and input :-) > You're welcome. Thanks, Amir.
