Message-ID: <fcwsytw5kd44veyzfel3uxwk2xsi4ywcy354s7rwaj7v4okwf7@ou4nmbo6eixo>
Date: Sun, 11 Jan 2026 12:20:52 -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>, 
	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>, Chen Linxuan <chenlinxuan@...ontech.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, 
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev, 
	linux-cxl@...r.kernel.org, linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH V3 13/21] famfs_fuse: Famfs mount opt: -o
 shadow=<shadowpath>

On 26/01/09 06:38PM, John Groves wrote:
> On 26/01/09 11:22AM, Joanne Koong wrote:
> > On Wed, Jan 7, 2026 at 7:34 AM John Groves <John@...ves.net> wrote:
> > >
> > > The shadow path is a (usually in tmpfs) file system area used by the
> > > famfs user space to communicate with the famfs fuse server. There is a
> > > minor dilemma that the user space tools must be able to resolve from a
> > > mount point path to a shadow path. Passing in the 'shadow=<path>'
> > > argument at mount time causes the shadow path to be exposed via
> > > /proc/mounts, Solving this dilemma. The shadow path is not otherwise
> > > used in the kernel.
> > 
> > Instead of using mount options to pass the userspace metadata, could
> > /sys/fs be used instead? The client is able to get the connection id
> > by stat-ing the famfs mount path. There could be a
> > /sys/fs/fuse/connections/{id}/metadata file that the server fills out
> > with whatever metadata needs to be read by the client. Having
> > something like this would be useful to non-famfs servers as well.
> 
> The shadow option isn't the only possible way to get what famfs needs,
> but I do like it - I find it to be an elegant solution to the problem.
> 
> What's the problem? Well, for that you need to know some implementation 
> details of the famfs userspace. For the *structure* of a mounted file 
> system, famfs is very passthrough-like. The structure that is being 
> passed through is the shadow file system, which is an actual file system 
> (usually tmpfs).  Directories are just directories, but shadow files 
> contain yaml that describes the file-to-dax map of the *actual* file. 
> On lookup, the famfs fuse server (famfs_fused), rather than stat the 
> file like passthrough, reads the yaml and decodes the stat and fmap info 
> from that.
> 
> One other detail. The shadow path must be known or created (usually
> as a tmpdir, to guarantee it starts empty) at mount time. The kernel
> knows about it through "-o shadow=<path>", but otherwise doesn't use
> it. The famfs fuse server receives the path as an input from 
> 'famfs mount'. The problem is that pretty much every famfs-related
> user space command needs the shadow path.
> 
> In fact the the structure of the mounted file system is at 
> <shadow_path>/root.  Also located in <shadow path> (above ./root) is a 
> unix domain socket for REST communication with famfs_fused. We have 
> plans for other files at <shadow path> and above ./root (mount-specific 
> config options, for example).
> 
> Playing the famfs metadata log requires finding the shadow path,
> parsing the log, and creating (or potentially modifying) shadow files
> in the shadow path for the mount.
> 
> So to communicate with the fuse server we parse the shadow path from
> /proc/mounts and that finds the <shadow_path>/socket that can be used
> to communicate with famfs_fused. And we can play the metadata log
> (accessed via MPT/.meta/.log) to <shadow_path>/root/...
> 
> Having something in sysfs would be fine, but unless we pass it into
> the kernel somehow (hey, like -o shadow=<shadow path>), the kernel
> won't know it and can't reveal it.
> 
> A big no-go, I think, is trying to parse the shadow path from the
> famfs fuse server via 'ps -ef' or 'ps -ax'. The famfs cli etc. might
> be running in a container that doesn't have access to that.
> 
> Happy to discuss further...

After all that blather (from me), I've been thinking about resolving
mount points to shadow paths, and I came to the realization that it's
actually easy to enable retrieving the shadow path from the fuse
server as an extended attribute.

I implemented that this morning, and it appears to be passing all tests.
So I anticipate that I'll be able to drop this patch from the series
when I send V4 - which should be in the next few days unless discussion
heats up in the mean time.

Thinking back... when I implemented the '-o shadow=<path>' thingy
more than a year ago, I still had a *lot* of unsolved problems to 
tackle. Once I had "a solution" I moved on - but the xattr idea looks
solid to me (though if anybody can point out flaws, I'd appreciate it).

(there's an Alice's Restaurant joke in there somewhere if you squint,
about not having to take out the garbage for a long time, but probably 
only for old people like me...)

Regards,
John

[ ... ]

Powered by blists - more mailing lists