--scope in addition to --current-mount

[porg]

• 👍 It is very cool per se that one can limit the scope of what storage device is monitored.
  • 👍 --current-mount is a nice shortcut if your current working directory is on the device which you want to monitor.
• 👎 But that this is the only way to filter, is not so convenient.
  • In order to filter, one must first always cd into the storage device one wants to monitor.
  • I'd prefer that I could stay were I am and nevertheless monitor a particular storage device.

Proposal

• --scope < filepath | devicepath > lets you limit the monitoring scope
  • /path/to/mountpoint/
  • /path/to/mountpoint/and/particular/dir/
  • /dev/sda/ any partition/filesystem on HDD "a"
  • /dev/sda2/ particular partition "nr. 2" on particular HDD "a"

[porg]

Any plans for implementation?

[KaelWD]

Would it be possible to specify a filesystem instead of a mount? For example --scope /dev/mmcblk1p1 so I can ignore writes captured by folder2ram.

[porg]

@KaelWD That use case certainly is in the spirit of my proposal. I extended the proposal accordingly. Thanks!

@martinpitt Any plans?

[mrob27]

Regarding the "/dev/sda or /dev/sda2" example, it occurs to me that the intended use of the feature would be to discover why a rotating hard disk is being used (as evidenced by hearing the sounds that such a device makes). However I should point out that the proliferation (and overuse) of btrfs means that it is common for filesystems to be spread across two devices of different types (a rotating disk and an SSD) which makes such an option less likely to be actually useful -- when / and /home are both spread across both drives, every I/O will cause both drives to be activated.

(Also I'll note that using btrfs that way greatly increases the liklihood of total data loss, because the loss of either physical drive means the loss of every btrfs partition that is using it, but that doesn't stop Linux distros from blithely going ahead and doing it anyway.)

[KaelWD]

In my case I was using it to find out what's writing to my pi's SD card (ext4) constantly. Some writes are already intercepted by https://github.com/bobafetthotmail/folder2ram so don't make it to the actual device, but still flood fatrace's log with events.

[mrob27]

Is there a way to tell the kernel API to watch for activity in a certain directory? If so, then the way to implement this would be simple, just ask the kernel to monitor the --scope directory.
According to the @KaelWD comment right before this comment it appears that they want a "--exclude-scope" option (I don't know why is this called a "scope" instead of a "directory"). That would cause fatrace to not print out any "events" that happen inside the exclude-scope'd directory. The way to implement that would be to scan through all the directories on every mounted drive and tell the kernel that we want to monitor only those directories that do not include the --exclude-scope'd directory(ies). You can give the option more than once to filter out multiple directories. If that implementation is not possible with the kernel API, then instead fatrace could do the filtering itself. That would be more efficient than using a grep or egrep filter on the fatrace output (which seems to be what @KaelWD would be doing right now and maybe why they want the feature)

[porg]

I proposed this feature, and in my original post it says:

--scope < filepath | devicepath > lets you limit the monitoring scope

• By default --scope is /. If you specify a --scope you narrow the scope to your given filepath/devicepath. So you see only events from the scope and everything else is not shown. e.g. only show my events from the HDD at /dev/sdb.

• If we had and argument like --exclude then you would get all events from / minus the excluded filepath/devicepath, e.g. SD card events shall be shown but please --exclude /path/to/folder2ram-dir/.

[martinpitt]

I'm fine with generalizing --current-mount to an option which takes the mount at a given directory, like --mount-at <dir>. It doesn't really add anything new, as you can always do ( cd <dir>; fatrace --current-mount), but it saves some typing.

I don't like the "device name" argument, though. fanotify() just doesn't work at the device level, but at the VFS level. Mounts and devices have an N:M relationship, including 0 for either N or M. E.g. there's MD, devmapper, RAID, btrfs, LVM, stratis, loop devices, which make mapping a device to a mount rather hard. Conversely, if there is a device which isn't mounted, you can't map it to any filesystem path. And then there's virtual file systems like tmpfs or procfs which don't have any underlying devices.

--exclude doesn't really add anything fundamentally new: you can always do fatrace [...] | grep to filter for a subdirectory, or grep -v to exclude one. I'd rather re-use existing (and much more flexible) tools than adding a less powerful reimplementation of that to fatrace -- this is supposed to be a simple building block.

[svenssonaxel]

Perhaps #48 can be extended to detect whether the directory is a mount point, and in that case watch the mount rather than a directory tree. I believe that would cover the same use case as this proposal.

[kotsmotritnastul]

I am using this clunky workaround to filter fatrace output

sudo unbuffer fatrace -f W | awk '!/PATH_I_DONT_WANT_TO_TRACK/'

maybe it will be useful for you too. but option like --exclude would be more convenient.

[porg]

@svenssonaxel thanks for notifying me about your PR #48 in in your comment #18 (comment)

• --dir as implemented is helpful for monitoring particular directories in a resource efficient way (compared to querying a top level mount point and then pipe all through grep and filter there)
• But given that it is not recursive it is not suited for the use case of monitoring everything below a /certain/path/*
  • If that cannot be made in an efficient query to the kernel, then I think this is out of scope for fatrace and piping it forward to grep is the way to go in the Unix spirit of "do one thing and do it well.".

[porg]

@mrob27 to answer your question from #18 (comment)

I don't know why is this called a "scope" instead of a "directory"?

I choose --scope consciously as an umbrella term for device path OR directory path OR mount path.