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

From: Miklos Szeredi <miklos@szeredi.hu>
To: Josef Bacik <josef@toxicpanda.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Amir Goldstein <amir73il@gmail.com>, Jan Kara <jack@suse.cz>,
	 Christian Brauner <brauner@kernel.org>, 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: Fri, 27 Oct 2023 15:47:49 +0200	[thread overview]
Message-ID: <CAJfpeguvpp-a3p1FdYyRsVUUzueqGFVqqAB3yoYO7HsQdyqdLQ@mail.gmail.com> (raw)
In-Reply-To: <20231027131726.GA2915471@perftesting>

On Fri, 27 Oct 2023 at 15:17, Josef Bacik <josef@toxicpanda.com> wrote:

> I have to support this file system in the real world, with real world stupidity
> happening that I can't control.  I wholeheartedly agree that the statx fields
> are not a direct fix, it's a comprimise.  It's a way forward to let the users
> who care about the distinction be able to get the information they need to make
> better decisions about what to do when they run into btrfs's weirdness.  It
> doesn't solve the st_dev problem today, or even for a couple of years, but it
> gives us a way to eventually change the st_dev thing.  Thanks,

This is very similar to the problem that overlayfs is trying hard to
work around: unifying more than one st_ino namespace into a single
st_ino namespace.    Btrfs used st_dev, overlayfs is using the high
bits of st_ino.  Both of these are hacks.

Adding one more 64bit field doesn't look like a proper solution: now
overlayfs will have to fit multiple 128bit namespace into a single
128bit namespace.

Not sure what's the right answer, but file handles come to mind, since
they have some nice properties:

 - not reused after unlink
 - variable length

Thanks,
Miklos