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

From: Miklos Szeredi <miklos@szeredi.hu>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Abel Wu <wuyun.abel@bytedance.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Christian Brauner <brauner@kernel.org>,
	Linux API <linux-api@vger.kernel.org>,
	linux-man <linux-man@vger.kernel.org>,
	David Howells <dhowells@redhat.com>,
	Al Viro <viro@zeniv.linux.org.uk>,
	Christian Brauner <christian@brauner.io>,
	lsf-pc <lsf-pc@lists.linux-foundation.org>
Subject: Re: [LSF/MM TOPIC] fsinfo and mount namespace notifications
Date: Tue, 18 Apr 2023 10:54:11 +0200	[thread overview]
Message-ID: <CAJfpegsLD-OxYfqPR7AfWbgE1EAPfWs672omt+_u8sYCMFB5Fg@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxhYi2823GiVn9Sf-CRGrcigkbPw2x1VQRV3_Md92gJnrw@mail.gmail.com>

On Sat, 15 Apr 2023 at 13:06, Amir Goldstein <amir73il@gmail.com> 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

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@warthog.procyon.org.uk/

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.

- getxattr(":mntns:$ID:info",...)

https://lore.kernel.org/all/YnEeuw6fd1A8usjj@miu.piliscsaba.redhat.com/

Christian would like to see the xattr based interface replaced with a
new set of syscalls to avoid confusion with "plain" xattrs.

Thanks,
Miklos