On Wed, 19 Apr 2023 at 10:18, Amir Goldstein <amir73il@xxxxxxxxx> wrote: > > On Tue, Apr 18, 2023 at 9:57 PM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > 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. > > > > 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
