Re: [PATCH 0/3] fanotify support for btrfs sub-volumes

Christoph Hellwig
2023-11-08T07:56:27Z

On Tue, Nov 07, 2023 at 09:58:48AM +0100, Christian Brauner wrote:
> > 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.

І'm not sure why you're trying to overload words with meanings that
weren't said. If you list software that is both by it's place in the
food chain and by its developer community very up to date to low-level
Linux quirks (sometimes too much, btw - we really should accomodate
them better), it shows a somewhat limited view, which is the definition
of a bubble. There is absolutely no implication that this is intentional
or even malicious.

> > 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.

a bind mount can of course change the dev_t - if it points to a
different super block at the moment.