On Mon, Nov 06, 2023 at 09:10:28AM -0800, Christoph Hellwig wrote: > On Mon, Nov 06, 2023 at 02:05:45PM +0100, Christian Brauner wrote: > > > > I think spending time engaging this claim isn't worth it. This is just > > > > easily falsifiable via a simple grep for btrfs in systemd, lxc, runc, > > > > util-linux. > > > > > > Myabe you need to get our of your little bubble. There is plenty of > > > > Unnecessary personal comment, let alone that I'm not in any specific > > bubble just because I'm trying to be aware of what is currently going on > > in userspace. > > Maybe you're just taking it to personal? A place where systemd, lxc, Of course I'm taking that personal. It's a personal comment that unnecessarily accompanies the message that you think I discount software that isn't all that modern. Which is a fair point. It doesn't have to come with garnish about me living in a bubble. Which is also a little insulting because you very well know that I spend hours each cycle fixing all kinds of weird regressions from software from the stone age. > runc, and util-linux are "all software" is a very much a bubble as you > won't find much userspace that stays more uptodate with particular > quirks of modern Linux features. You assume that your solution doesn't break things. And it will. For btrfs users and for other userspace tools as well. As detailed in other parts of the thread. > > > Whatever you do here: vfsmounts or any other solution will force changes > > in userspace on a larger scale and changes to the filesystem itself. If > > you accommodate tar then you are fscking over other parts of userspace > > which are equally important. There is no free lunch. > > It works for everything that knows that Linux mountpoint as exposed > in /proc/mounts and proc/self/mountinfo corresponds to the posix > definition of a mount point, and that one used on basically every > other unix system. It might not work as-is for software that actually > particularly knows how to manage btrfs subvolumes, but those are, by > defintion, not the problem anyway. On current systems and since forever bind-mounts do not change device numbers unless they are a new filesystem mount. Making subvolumes vfsmounts breaks that. That'll mean a uapi change for /proc/<pid>/mountinfo for a start. It also risks immediately breaking basic stuff such as associating vfsmounts with the superblock they belong to via device numbers from parsing /proc/<pid>/mountinfo. And see other mails for other side-effects of this. All of this also discounts the invasive effects that it will have when you suddenly start plopping automounts into the mount tables of processes on lookup and propagting subvolumes as vfsmounts into random mount namespaces. I've detailed problems with automounts that btrfs would get themselves into elsewhere so I'm not going to repeat it here.
