On Fri, Oct 27, 2023 at 09:17:26AM -0400, Josef Bacik wrote: > We have this same discussion every time, and every time you stop responding > after I point out the problems with it. I'm not sure why you think I stop responding when the action item is not for me. > A per-subvolume vfsmount means that /proc/mounts /proc/$PID/mountinfo becomes > insanely dumb. I've got millions of machines in this fleet with thousands of > subvolumes. One of our workloads fires up several containers per task and runs > multiple tasks per machine, so on the order of 10-20k subvolumes. If you do not expose them in /proc/mounts and friends you don't have any way to show where the mount point or whatever barrier you want between different st_dev/fsid/etc is. And you need that. I've not seen any good alternative that keeps the invariant and doesn't break things. If you think there is one please explain it, but no, adding new fields so that new software can see how we've broken all the old software is not the answer. A (not really) great partial answer would be to stop parsing the text mount information so much, at least for your workloads that definitively are little on the extreme side. I think Miklos has been working on interface that could be useful for that.
