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...
>
> 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.
Thanks Darrick!
John
<snip>
