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

From: Christoph Hellwig <hch@infradead.org>
To: Christian Brauner <brauner@kernel.org>
Cc: Christoph Hellwig <hch@infradead.org>,
	Josef Bacik <josef@toxicpanda.com>,
	Qu Wenruo <quwenruo.btrfs@gmx.com>,
	Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>,
	Chris Mason <clm@fb.com>, David Sterba <dsterba@suse.com>,
	linux-btrfs@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 0/3] fanotify support for btrfs sub-volumes
Date: Wed, 8 Nov 2023 22:53:40 -0800	[thread overview]
Message-ID: <ZUyB9Dr8rOnmNwtH@infradead.org> (raw)
In-Reply-To: <20231108-atemwege-polterabend-694ca7612cf8@brauner>

On Wed, Nov 08, 2023 at 05:16:32PM +0100, Christian Brauner wrote:
> > Well, if we want to legitimize the historic btrfs behavior the way to
> > find out is if st_dev changes without that being a mount point, so
> > an extra flag would be redundant.
> 
> The device number may also change on overlayfs per directory in certain
> circumstances so it doesn't work in the general case.
> 
> Plus that requires a lot of gymnastics in the general case as you need
> to statx() the file, call statfs() to figure out that it is a btrfs
> filesystem, retrieve the device number of the superblock/filesystem and
> compare that with the device number returned from stat(). And that's the
> btrfs specific case.

Why would you care about the device of the super block?  You need to
compare it with the parent.

> For bcachefs this doesn't work because it doesn't
> seem to change st_dev.

Well, that's going to be really broken then.  But hey, if we merge
these kinds of things without review we'll have to live ith it :(

But maybe we just need to throw in the towel when we have three
file systems now that think they can just do random undocument and
not backward compatbile things with their inode numbers and declare
the inode number of a compeltely meaningless cookie..