On Thu, Apr 24, 2025 at 08:43:33AM -0500, John Groves wrote:
> On 25/04/20 08:33PM, John Groves wrote:
> > On completion of GET_FMAP message/response, setup the full famfs
> > metadata such that it's possible to handle read/write/mmap directly to
> > dax. Note that the devdax_iomap plumbing is not in yet...
> >
> > Update MAINTAINERS for the new files.
> >
> > Signed-off-by: John Groves <john@xxxxxxxxxx>
> > ---
> > MAINTAINERS | 9 +
> > fs/fuse/Makefile | 2 +-
> > fs/fuse/dir.c | 3 +
> > fs/fuse/famfs.c | 344 ++++++++++++++++++++++++++++++++++++++
> > fs/fuse/famfs_kfmap.h | 63 +++++++
> > fs/fuse/fuse_i.h | 16 +-
> > fs/fuse/inode.c | 2 +-
> > include/uapi/linux/fuse.h | 42 +++++
> > 8 files changed, 477 insertions(+), 4 deletions(-)
> > create mode 100644 fs/fuse/famfs.c
> > create mode 100644 fs/fuse/famfs_kfmap.h
> >
<snip>
> > diff --git a/include/uapi/linux/fuse.h b/include/uapi/linux/fuse.h
> > index d85fb692cf3b..0f6ff1ffb23d 100644
> > --- a/include/uapi/linux/fuse.h
> > +++ b/include/uapi/linux/fuse.h
> > @@ -1286,4 +1286,46 @@ struct fuse_uring_cmd_req {
> > uint8_t padding[6];
> > };
> >
> > +/* Famfs fmap message components */
> > +
> > +#define FAMFS_FMAP_VERSION 1
> > +
> > +#define FUSE_FAMFS_MAX_EXTENTS 2
> > +#define FUSE_FAMFS_MAX_STRIPS 16
>
> FYI, after thinking through the conversation with Darrick, I'm planning
> to drop FUSE_FAMFS_MAX_(EXTENTS|STRIPS) in the next version. In the
> response to GET_FMAP, it's the structures below serialized into a message
> buffer. If it fits, it's good - and if not it's invalid. When the
> in-memory metadata (defined in famfs_kfmap.h) gets assembled, if there is
> a reason to apply limits it can be done - but I don't currently see a reason
> do to that (so if I'm currently enforcing limits there, I'll probably drop
> that.
You could also define GET_FMAP to have an offset in the request buffer,
and have the famfs daemon send back the next offset at the end of its
reply (or -1ULL to stop). Then the kernel can call GET_FMAP again with
that new offset to get more mappings.
Though at this point maybe it should go the /other/ way, where the fuse
server can sends a "notification" to the kernel to populate its mapping
data? fuse already defines a handful of notifications for invalidating
pagecache and directory links.
(Ugly wart: notifications aren't yet implemented for the iouring channel)
--D
>
> > +
> > +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;
> > +};
> > #endif /* _LINUX_FUSE_H */
> > --
> > 2.49.0
> >
