On Tue, 18 Apr 2023 at 17:57, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Tue, Apr 18, 2023 at 11:54 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > - mount ID's do not uniquely identify a mount across time > > o when a mount is deleted, the ID can be immediately reused > > > > The following are the minimal requirements needed to fix the above issues: > > > > 1) create a new ID for each mount that is unique across time; lets > > call this umntid > > > > Do you reckon we just stop recycling mntid? > Do we also need to make it 64bit? > statx() has already allocated 64bit for stx_mnt_id. > In that case, should name_to_handle_at() return a truncated mnt_id? I'm not sure it's realistic to implement the new 64bit ID such that the truncated value retains the properties of the previous mount ID implementation. I think the only sane option is to leave the old mnt_id alone and add a new 64bit one that is assigned from an atomic counter at allocation and looked up using a hash table. > > - mount notifications using watch_queue > > > > https://lore.kernel.org/all/159645997768.1779777.8286723139418624756.stgit@xxxxxxxxxxxxxxxxxxxxxx/ > > > > I also explored fsnotify infrastructure for this. I think the API is > > better fit, since we are talking about filesystem related events, but > > notifications l would need to be extended with the mount ID. > > Like this? ;-) > > https://lore.kernel.org/linux-fsdevel/20230414182903.1852019-1-amir73il@xxxxxxxxx/ > > I was considering whether fanotify should report a 32bit mntid > (like name_to_handle_at()) or 64bit one (like statx()). > I should probably go with the latter then. Or a 32+64bit one, like I said. Thanks, Miklos
