On Fri 27-10-23 00:30:29, Christoph Hellwig wrote: > On Fri, Oct 27, 2023 at 09:33:19AM +0300, Amir Goldstein wrote: > > OK. You are blaming me for attempting to sneak in a broken feature > > and I have blamed you for trying take my patches hostage to > > promote your agenda. > > I'm not blaming you for anything. But I absolutely reject spreading > this broken behavior to core. That's why there is hard NAK on this > patchs. > > > > > If that is the case, fanotify will need to continue reporting the fsid's > > exactly as the user observes them on the legacy btrfs filesystems. > > The v2 patches I posted are required to make that possible. > > The point is tht you simply can't use fanotify on a btrfs file system > with the broken behavior. That's what btrfs gets for doing this > broken behavior to start with. Well, fanotify was never disabled on btrfs and presumably there are users. What we blocked (exactly out of caution to not spread questionable behavior) is placing of marks using a path whose fsid (from statfs(2)) is different from filesystem root fsid when using FID-mode fanotify group (i.e. groups where we report fsid + fhandle for each event instead of open file descriptor). So effectively people currently cannot place marks on non-root subvolume paths of btrfs for such fanotify groups. Now given it is uncertain how exactly will filesystems end up presenting subvolumes to VFS (and consequently to userspace) I agree it is probably premature to allow placing superblock or mount marks on such paths because the meaning could change when btrfs changes its presentation and we'd be just adding ourselves more headaches with backward compatibility for no great reasons. But so far I see no good reason to keep forbidding adding inode marks on such paths as Amir suggests. I'll think about that. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
