> On Nov 7, 2024, at 3:10 AM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Wed, Oct 30, 2024 at 12:13 AM Song Liu <song@xxxxxxxxxx> wrote: >> >> This test shows a simplified logic that monitors a subtree. This is >> simplified as it doesn't handle all the scenarios, such as: >> >> 1) moving a subsubtree into/outof the being monitoring subtree; > > There is a solution for that (see below) > >> 2) mount point inside the being monitored subtree > > For that we will need to add the MOUNT/UNMOUNT/MOVE_MOUNT events, > but those have been requested by userspace anyway. > >> >> Therefore, this is not to show a way to reliably monitor a subtree. >> Instead, this is to test the functionalities of bpf based fastpath. >> To really monitor a subtree reliably, we will need more complex logic. > > Actually, this example is the foundation of my vision for efficient and race > free subtree filtering: > > 1. The inode map is to be treated as a cache for the is_subdir() query Using is_subdir() as the truth and managing the cache in inode map seems promising to me. > 2. Cache entries can also have a "distance from root" (i.e. depth) value > 3. Each unknown queried path can call is_subdir() and populate the cache > entries for all ancestors > 4. The cache/map size should be limited and when limit is reached, > evicting entries by depth priority makes sense > 5. A rename event for a directory whose inode is in the map and whose > new parent is not in the map or has a different value than old parent > needs to invalidate the entire map > 6. fast_path also needs a hook from inode evict to clear cache entries The inode map is physically attached to the inode itself. So the evict event is automatically handled. IOW, an inode's entry in the inode map is automatically removed when the inode is freed. For the same reason, we don't need to set a limit in map size and add evicting logic. Of course, this works based on the assumption that we don't use too much memory for each inode. I think this assumption is true. > > This is similar, but more efficient and race free than what could already > be achieved in userspace using FAN_MARK_EVICTABLE. > > Food for thought. Thanks, Song
