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.
