Bug#940629: fatrace: add support for detecting rename events
Martin Pitt [2019-09-29 21:43 +0200]: > I made some initial experiments with this today [1], on kernel 5.3. (Note that > this won't eventually look like this, there needs to be a fallback for older > kernels.) But so far this isn't encouraging -- the results for "normal" > open/close/read/write are much worse. In particular, I get a lot of ESTALE > event fds now that previously resolved to existing files just fine, and also > the pid → /proc/pid/comm resolution is now much less reliable. Note for myself: I found out the root cause: It's in the file_handle → fd resolution in event_fd = open_by_handle_at(AT_FDCWD, (struct file_handle *) fid->handle, O_RDONLY); Due to the AT_FDCWD this only works for events that are on the same file system as the cwd of fatrace (e. g. in --current-mount mode). There is some impedance mismatch of the fanotify FAN_EVENT_INFO_TYPE_FID API, which only delivers the rather useless "fsid", and open_by_handle_at() which expects "some fd from the mount point that contains the file handle". So in "global" (not --current-mount) mode, this could work like this: When iterating over /proc/self/mounts when setting up fanotifys for every mount, open the mount point as "mount_fd", statfs() it, and remember a map fsid → mount_fd, and do lookups in print_event when it calls open_by_handle_at(). I'll look at this at some later time. Martin
Bug#940629: fatrace: add support for detecting rename events
Hello Paul, Paul Wise [2019-09-18 12:20 +0800]: > Linux fanotify now supports detecting file renames, it would be nice to > have support for those (AFAICT there is no support for them yet) and for any > other fanotify events that have been added in recent years. This isn't the first time I get this request, and it has bothered me as well. Detecting renames and also deletions should be possible with the very new (Linux 5.1, i. e. 4 months old) FAN_REPORT_FID mode. I made some initial experiments with this today [1], on kernel 5.3. (Note that this won't eventually look like this, there needs to be a fallback for older kernels.) But so far this isn't encouraging -- the results for "normal" open/close/read/write are much worse. In particular, I get a lot of ESTALE event fds now that previously resolved to existing files just fine, and also the pid → /proc/pid/comm resolution is now much less reliable. Currently this feels like a bad trade-off to make, but I'll investigate this further. Martin [1] https://paste.fedoraproject.org/paste/6IjETdiFcz3E3hrYWilbqA
Bug#940629: fatrace: add support for detecting rename events
Package: fatrace Version: 0.13-2 Severity: wishlist Linux fanotify now supports detecting file renames, it would be nice to have support for those (AFAICT there is no support for them yet) and for any other fanotify events that have been added in recent years. https://lwn.net/Articles/717060/ -- System Information: Debian Release: bullseye/sid APT prefers testing-debug APT policy: (900, 'testing-debug'), (900, 'testing'), (800, 'unstable-debug'), (800, 'unstable'), (790, 'buildd-unstable'), (700, 'experimental-debug'), (700, 'experimental'), (690, 'buildd-experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.2.0-2-amd64 (SMP w/4 CPU cores) Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_AU.utf8, LC_CTYPE=en_AU.utf8 (charmap=UTF-8), LANGUAGE=en_AU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fatrace depends on: ii libc6 2.29-1 Versions of packages fatrace recommends: ii powertop 2.10-1+b1 ii python3 3.7.3-1 fatrace suggests no packages. -- no debconf information -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
