Re: [LSF/MM TOPIC] fsinfo and mount namespace notifications

[Miklos Szeredi <miklos@szeredi.hu>]

On Wed, 19 Apr 2023 at 10:18, Amir Goldstein <amir73il@gmail.com> wrote:
>
> On Tue, Apr 18, 2023 at 9:57 PM Miklos Szeredi <miklos@szeredi.hu> wrote:
> >
> > On Tue, 18 Apr 2023 at 17:57, Amir Goldstein <amir73il@gmail.com> wrote:
> > >
> > > On Tue, Apr 18, 2023 at 11:54 AM Miklos Szeredi <miklos@szeredi.hu> 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.
> >
>
> At the risk of shoehorning, that sounds a bit like file_handle of a mount.
> Meaning that it could be the result of
>
> name_to_handle_at(...,&mount_handle, &mount_id, AT_MNTID)
>
> We can possibly use open_by_handle_at() to get a mountfd from
> mount_handle - not sure if that makes sesnse.
>

There are conceptual similarities, yes.  Whether reusing the file
handle interfaces makes sense or not is another question.


> [...]
>
> > > > 3) allow querying mount parameters via umntid
>
> I forgot to mention in the context of this topic, that there was a
> topic proposal
> about using "BFP iterator" [1] to query fs/mount info.
>
> I don't know if that can be used to get namespace change notifications
> or if it meets other requirements (i.e. permissions), but wanted to
> mention it here.
>
> I think we can discuss both topics in the same session.

Okay.

Thanks,
Miklos