Re: [PATCH V10 00/10] famfs: port into fuse

[Joanne Koong]

On Thu, Apr 16, 2026 at 1:14 PM Gregory Price <gourry@xxxxxxxxxx> wrote:
>
> On Thu, Apr 16, 2026 at 08:56:46AM -0700, Joanne Koong wrote:
> > On Tue, Apr 14, 2026 at 5:10 PM John Groves <John@xxxxxxxxxx> wrote:
> > >
> > > There is a FUSE_DAX_FMAP capability that the kernel may advertise or not
> > > at init time; this capability "is" the famfs GET_FMAP AND GET_DAXDEV
> > > commands. In the future, if we find a way to use BPF (or some other
> > > mechanism) to avoid needing those fuse messages, the kernel could be updated
> > > to NEVER advertise the FUSE_DAX_FMAP capability. All of the famfs-specific
> > > code could be taken out of kernels that never advertise that capability.
> >
> > I’m not sure the capability bit can be used like that (though I am
> > hoping it can!). As I understand it, once the kernel advertises a
> > capability, it must continue supporting it in future kernels else
> > userspace programs that rely on it will break.
> >
>
> FUSE_DAX_FMAP is already conditional on CONFIG_FUSE_DAX, the kernel is
> not required to continue advertising FUSE_DAX_FMAP in perpetuity.
>
> Setting CONFIG_FUSE_DAX=n does not mean userland "is broken", this would
> only be the case if FUSE_DAX_FMAP was advertised but not actually
> supported.
>
> If DAX were removed from the kernel (unlikely, but stick with me) this
> would be equivalent to permanently changing CONFIG_FUSE_DAX to always
> off, and there would be no squabbles over whether that particular
> change broke userland (there would be much strife over removing dax).
>
> While not a deprecation method, this is what capability bits are
> designed for. Same as cpuid capability bits - just because the bit is
> there doesn't mean a processor is required to support it in perpetuity.
>
> They're only required to support it if the bit is turned on.
>
> ---
>
> I think the focus here needs to be on whether this interface ACTUALLY
> needs to be more generic - and whether that is actually FEASIBLE.
>
> It's not like this is a new problem - and there are real design reasons
> why John chose this route.
>
> The additional overhead is not trivial for FAMFS - FAMFS is not doing
> i/o.  He already has data showing fuse caused a performance hit due to
> overhead on open - his concern of overhead on fault being catastrophic
> is grounded in data.
>
> For others it's an age old problem of self-describing protocols (parsing
> vs giant inflexible binary blobs, pick your poison).  It's extremely
> unlikely we will find a one-size-fits-all solution that doesn't
> eventually run right back into this same problem.
>
> I worry that this discussion is going to turn towards implementing a
> solution grounded in parsing arbitrary formats and how to store them,
> and that is completely detached from why FAMFS went this route in the
> first place.
>
> I question whether the actual issue here lies in the interface APPEARING
> more general purpose than it actually is - and therefore inviting
> attempts to over-genericize it.

Would you mind clarifying this part? Are you saying that the interface
and logic is *already* generic and usable for other dax-backed
servers, just that everything is *named* famfs but it's not really
famfs specific? That's what I was trying to figure out - looking at
the uapi, it seems pretty generic with defining bytes, strips, chunk
size, etc which all seem like general concepts but the naming of it is
so implementation-specific, eg

enum fuse_famfs_file_type {
        FUSE_FAMFS_FILE_REG,
        FUSE_FAMFS_FILE_SUPERBLOCK,
        FUSE_FAMFS_FILE_LOG,
};

enum famfs_ext_type {
        FUSE_FAMFS_EXT_SIMPLE = 0,
        FUSE_FAMFS_EXT_INTERLEAVE = 1,
};

struct fuse_famfs_simple_ext {
        uint32_t se_devindex;
        uint32_t reserved;
        uint64_t se_offset;
        uint64_t se_len;
};

struct fuse_famfs_iext { /* Interleaved extent */
        uint32_t ie_nstrips;
        uint32_t ie_chunk_size;
        uint64_t ie_nbytes; /* Total bytes for this interleaved_ext;
                             * sum of strips may be more
                             */
        uint64_t reserved;
};

struct fuse_famfs_fmap_header {
        uint8_t file_type; /* enum famfs_file_type */
        uint8_t reserved;
        uint16_t fmap_version;
        uint32_t ext_type; /* enum famfs_log_ext_type */
        uint32_t nextents;
        uint32_t reserved0;
        uint64_t file_size;
        uint64_t reserved1;
};

which made me think this is only famfs-specific. Are all of these
reusable / generally applicable structs? And just to double-check, the
computation logic in patch 6 [1] would be generic to other dax-backed
servers as well or is that part famfs-specific?

Thanks,
Joanne

[1] https://lore.kernel.org/linux-fsdevel/0100019d43e79794-0eadcf5e-b659-43f7-8fdc-dec9f4ccce14-000000@xxxxxxxxxxxxxxxxxxx/
>
> Is there a world here where this is solved by a name change and a
> capability bit?  I think so.
>
> ~Gregory