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 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. - 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. Thanks, Miklos
