Re: [RFC V2 11/18] famfs_fuse: Basic famfs mount opts

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, Jul 11, 2025 at 10:28:20AM -0500, John Groves wrote:
> On 25/07/08 08:59PM, Darrick J. Wong wrote:
> > On Thu, Jul 03, 2025 at 01:50:25PM -0500, John Groves wrote:
> > > * -o shadow=<shadowpath>
> > 
> > What is a shadow?
> > 
> > > * -o daxdev=<daxdev>
> 
> Derp - OK, that's a stale commit message. Here is the one for the -next
> version of this patch:
> 
>     famfs_fuse: Basic famfs mount opt: -o shadow=<shadowpath>
> 
>     The shadow path is a (usually tmpfs) file system area used by the famfs 
>     user space to commuicate 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. The shadow path is exposed via /proc/mounts, 
>     but otherwise not used by the kernel. User space gets the shadow path 
>     from /proc/mounts...

Ah.  A service directory, of sorts.

> > And, uh, if there's a FUSE_GET_DAXDEV command, then what does this mount
> > option do?  Pre-populate the first element of that set?
> > 
> > --D
> > 
> 
> I took out -o daxdev, but had failed to update the commit msg.
> 
> The logic is this: The general model requires the FUSE_GET_DAXDEV message /
> response, so passing in the primary daxdev as a -o arg creates two ways to
> do the same thing.
> 
> The only initial heartburn about this was one could imagine a case where a
> mount happens, but no I/O happens for a while so the mount could "succeed",
> only to fail later if the primary daxdev could not be accessed.
> 
> But this can't happen with famfs, because the mount procedure includes 
> creating "meta files" - .meta/.superblock and .meta/.log and accessing them
> immediately. So it is guaranteed that FUSE_GET_DAXDEV will be sent right away,
> and if it fails, the mount will be unwound.

<nod> 

--D

> Thanks Darrick!
> John
> 
> <snip>
> 
>