> > How about this compromise: > > > > - On fanotify_mark() call statfs() for both dentry and dentry->d_sb->sb_root > > - If they produce the same fsid, cache the fsid in the mark > > If they do not match invalidate existing cache and never check again > > - When encoding fid, use cached fsid if exists, otherwise fallback to > > statfs_by_dentry(find_any_alias(inode) ?: inode->i_sb->sb_root) > > I don't think this is really better - see my previous email. No I think it is horid, because results are unexpected and the same type of event on the same object can produce different fsid over time. > > > Maybe better to return -EXDEV from fanotify_mark() on mismatch of fsid > > of dentry and dentry->d_sb->sb_root? because it doesn't look like the > > FAN_MARK_FILESYSTEM is going to be very useful for btrfs (??). > > Well, I think FAN_MARK_FILESYSTEM is useful. Path events have no problem, I wasn't indenting to deny btrfs of FAN_MARK_FILESYSTEM with event->fd. Using a group with FAN_REPORT_FID will have limited support on btrfs (only for setting marks on root volume?). > events using FID will work as well when using open_by_handle(), just the > reported fsid may be confusing... I'm undecided what is better: returning > EXDEV or just silently dropping the other fsid. > As I wrote in other thread, I don't think open_by_handle() is really going to work. you may get an open file, but with an invalid path that is not useful for filesystem monitoring application. So if you don't object, I'll go with EXDEV and we can see later about relaxing it. Thanks, Amir.
