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> > >
