Message-ID: <aYy_c3Wh6RbJflvs@groves.net>
Date: Wed, 11 Feb 2026 12:26:47 -0600
From: John Groves <john@...ves.net>
To: Joanne Koong <joannelkoong@...il.com>
Cc: Miklos Szeredi <miklos@...redi.hu>, 
	Dan Williams <dan.j.williams@...el.com>, Bernd Schubert <bschubert@....com>, 
	Alison Schofield <alison.schofield@...el.com>, John Groves <jgroves@...ron.com>, 
	John Groves <jgroves@...tmail.com>, Jonathan Corbet <corbet@....net>, 
	Vishal Verma <vishal.l.verma@...el.com>, Dave Jiang <dave.jiang@...el.com>, 
	Matthew Wilcox <willy@...radead.org>, Jan Kara <jack@...e.cz>, 
	Alexander Viro <viro@...iv.linux.org.uk>, David Hildenbrand <david@...nel.org>, 
	Christian Brauner <brauner@...nel.org>, "Darrick J . Wong" <djwong@...nel.org>, 
	Randy Dunlap <rdunlap@...radead.org>, Jeff Layton <jlayton@...nel.org>, 
	Amir Goldstein <amir73il@...il.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>, 
	Stefan Hajnoczi <shajnocz@...hat.com>, Josef Bacik <josef@...icpanda.com>, 
	Bagas Sanjaya <bagasdotme@...il.com>, James Morse <james.morse@....com>, Fuad Tabba <tabba@...gle.com>, 
	Sean Christopherson <seanjc@...gle.com>, Shivank Garg <shivankg@....com>, 
	Ackerley Tng <ackerleytng@...gle.com>, Gregory Price <gourry@...rry.net>, 
	Aravind Ramesh <arramesh@...ron.com>, Ajay Joshi <ajayjoshi@...ron.com>, 
	"venkataravis@...ron.com" <venkataravis@...ron.com>, "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "nvdimm@...ts.linux.dev" <nvdimm@...ts.linux.dev>, 
	"linux-cxl@...r.kernel.org" <linux-cxl@...r.kernel.org>, "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>
Subject: Re: [PATCH V5 09/19] famfs_fuse: magic.h: Add famfs magic numbers

On 26/01/28 10:54AM, Joanne Koong wrote:
> On Wed, Jan 28, 2026 at 6:33 AM John Groves <john@...alactic.com> wrote:
> >
> > On 26/01/27 01:55PM, Joanne Koong wrote:
> > > On Fri, Jan 16, 2026 at 11:52 AM John Groves <john@...alactic.com> wrote:
> > > >
> > > > From: John Groves <john@...ves.net>
> > > >
> > > > Famfs distinguishes between its on-media and in-memory superblocks. This
> > > > reserves the numbers, but they are only used by the user space
> > > > components of famfs.
> > > >
> > > > Signed-off-by: John Groves <john@...ves.net>
> > > > ---
> > > >  include/uapi/linux/magic.h | 2 ++
> > > >  1 file changed, 2 insertions(+)
> > > >
> > > > diff --git a/include/uapi/linux/magic.h b/include/uapi/linux/magic.h
> > > > index 638ca21b7a90..712b097bf2a5 100644
> > > > --- a/include/uapi/linux/magic.h
> > > > +++ b/include/uapi/linux/magic.h
> > > > @@ -38,6 +38,8 @@
> > > >  #define OVERLAYFS_SUPER_MAGIC  0x794c7630
> > > >  #define FUSE_SUPER_MAGIC       0x65735546
> > > >  #define BCACHEFS_SUPER_MAGIC   0xca451a4e
> > > > +#define FAMFS_SUPER_MAGIC      0x87b282ff
> > > > +#define FAMFS_STATFS_MAGIC      0x87b282fd
> > >
> > > Could you explain why this needs to be added to uapi? If they are used
> > > only by userspace, does it make more sense for these constants to live
> > > in the userspace code instead?
> > >
> > > Thanks,
> > > Joanne
> >
> > Hi Joanne,
> >
> > I think this is where it belongs; one function of uapi/linux/magic.h is as
> > a "registry" of magic numbers, which do need to be unique because they're
> > the first step of recognizing what is on a device.
> >
> > This is a well-established ecosystem with block devices. Blkid / libblkid
> > scan block devices and keep a database of what devices exist and what
> > appears to be on them. When one adds a magic number that applies to block
> > devices, one sends a patch to util-linux (where blkid lives) to add ability
> > to recognize your media format (which IIRC includes the second recognition
> > step - if the magic # matches, verify the superblock checksum).
> >
> > For character dax devices the ecosystem isn't really there yet, but the
> > pattern is the same - and still makes sense.
> >
> > Also, 2 years ago in the very first public famfs patch set (pre-fuse),
> > Christian Brauner told me they belong here [1].

Apologies for not responding to this sooner.

First, FAMFS_STATFS_MAGIC will be dropped for sure. At one point I thought
I'd be able to override FUSE_SUPER_MAGIC in the output from statfs, but
that's not currently true. I've had to take a different approach in the 
famfs user space for definitively identifying whether a path falls in a 
famfs file system...

> 
> Hi John,
> 
> Thanks for the context. I was under the impression include/uapi/ was
> only for constants the kernel exposes as part of its ABI. If I'm
> understanding it correctly, FAMFS_SUPER_MAGIC is used purely as an
> on-disk format marker for identification by userspace tools. Why
> doesn't having the magic number defined in the equivalent of
> blkid/libblkid for dax devices and defined/used in the famfs
> server-side implementation suffice for that purpose? I'm asking in
> part because it seems like a slippery slope to me where any fuse
> server could make the same argument in the future that their magic
> constant should be added to uapi.

Right now there is no equivalent of util-linux/blkid for character device
superblock identification. Therefore this seems better than nothing to
record FAMFS_SUPER_MAGIC, since keeping it unique is a public good and
it is an actual on-media magic number. Although it's not currently used
on block devices, there is a very real possibility of famfs on block
devices in the future (pmem is block, and fs-dax, supporting that with
famfs would be straightforward, and there are problems for which it's a
good solution...)

There doesn't seem to be an explicit maintainer of magic.h; if somebody
can speak for the intent, or the rules etc., that would be helpful. I don't
want to abandon this based on general uapi guidelines alone. Is there
anybody in particular who should make a ruling here?

I don't really see a slippery slope; this isn't an arbitrary constant, 
it's an actual on-media magic number. 

> 
> For Christian's comment, my understanding was that with the pre-fuse
> patchset, it did need to be in uapi because the kernel explicitly set
> sb->s_magic to it, but with famfs now going through fuse, sb->s_magic
> uses FUSE_SUPER_MAGIC.

Even in the before-times with standalone famfs, on media (in-memory)
metadata was not accessed directly from the kernel module. So that didn't 
change with the fuse port (though it's possible that detail of the prior
implementation wasn't broadly understood...).

Would anybody like to weigh in to swing consensus here?

Thanks,
John

Powered by blists - more mailing lists