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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 18, 2023 at 11:54 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote:
>
> On Sat, 15 Apr 2023 at 13:06, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
>
> > You indicated that you would like to discuss the topic of
> > "mount info/mount notification" in LSF/MM, so I am resurrecting
> > this thread [1] from last year's topic.
> >
> > Would you be interested to lead a session this year?
> > So far, it felt like the topic was in a bit of a stalemate.
> >
> > Do you have a concrete suggestion of how to escape this stalemate?
> > I think it is better that we start discussing it a head of LSF/MM if we hope
> > to reach consensus in LSF/MM, so that people will have a chance to
> > get re-familiar with the problems and proposed solutions.
>
> The reason for the stalemate is possibly that we are not trying to
> solve the issue at hand...
>
> So first of all, here's what we currently have:
>
> - reading a process' mount table via /proc/$PID/mountinfo
>    o mount parameters (ID, parent ID, root path, mountpoint path,
> mount flags, propagation)
>    o super block parameters (devnum, fstype, source, options)
>    o need to iterate the whole list even if interested in just a single mount
>
> - notification on mount table change using poll on /proc/$PID/mountinfo
>    o no indication what changed
>    o finding out what changed needs to re-parse possibly the whole
> mountinfo file
>    o this can lead to performance problems if the table is large and
> constantly changing
>
> - 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?

> 2) notification needs to indicate the umntid that changed
>
> 3) allow querying mount parameters via umntid
>
> And I think here's where it gets bogged down due to everyone having
> their own ideas about how that interface should look like.
>
> Proposals that weren't rejected so far:
>
> - 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.

>
> - getxattr(":mntns:$ID:info",...)
>
> https://lore.kernel.org/all/YnEeuw6fd1A8usjj@xxxxxxxxxxxxxxxxxxxxxxxxx/
>
> Christian would like to see the xattr based interface replaced with a
> new set of syscalls to avoid confusion with "plain" xattrs.
>

OK, I penciled the session - we can (re)try to iron the concerns
and reach consensus.

Thanks,
Amir.




[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux