(sorry for the delayed reply, was OOO yesterday) On Thu, Jul 23, 2026 at 12:27 AM Miklos Szeredi <[email protected]> wrote: > > On Wed, 22 Jul 2026 at 16:43, Joanne Koong <[email protected]> wrote: > > > I had the same impression as Amir. The FUSE_DEV_IOC_STRIPE_OPEN patch > > [1] right now is only for the interleaved case to handle striping, but > > imo it seems a lot cleaner to make FUSE_DEV_IOC_STRIPE_OPEN a generic > > interface for handling any backing layout that corresponds to a > > backing id, and having the simple extent case go through this same > > infrastructure / path. Especially since John's future patches for > > adding the interleaving will go through the ioctl, it seems nicer > > server-side as well for famfs to have one consolidated path instead of > > needing two totally different ones. > > That's a valid point, but I still feel that those things are different. > > Striping: > - always static > - size limited by the number of devices > > Extent map: > - may be static (famfs) or dynamic (general block fs) > - size is unlimited > > Doing extent maps with an ioctl makes it clunky in the dynamic/unlimited case. > > > If not the ioctl, what did you have in mind for a generic interface? I > > think anything else would have to keep GET_FMAP, but maybe I'm wrong > > here. > > Good question. A NOTIFY_EXTENT_MAP (similar to Darrick's > FUSE_NOTIFY_IOMAP_UPSERT, but multiple extents) would work, I think.
This sounds great to me. As I understand it, the merge window for 7.3 closes at the end of August. Just to summarize, the only things needed to get this into 7.3 (besides addressing the Sashiko comments) are: a) replace FUSE_GET_FMAP with FUSE_NOTIFY_EXTENT_MAP (will also be good for famfs in general, saves an extra context switch) b) remove FUSE_DEV_IOC_DAXDEV_OPEN and reuse existing FUSE_DEV_IOC_BACKING_OPEN (logic for this already supplied in Miklos's patch in [1]) c) remove "config FUSE_FAMFS_DAX" d) remove FUSE_DAX_FMAP capability (not 100% sure about this, but since the only thing added to the uapi is a new notif type, seems fine to exclude this cap flag) Is this correct? I think with those changes, all the famfs/fmap-specific definitions will be cleared from the uapi. imo these changes seem doable for making the 7.3 merge window. I'm not sure how much bandwidth John has though. Maybe one idea that could work if John is completely slammed for time right now is having the changes requested above be a separate followup series someone else can do and then this current series (after the sashiko fixes) and that series can get landed together in the same merge window. > > Maybe the striping setup can also be done with a notification. The I had interpreted the FUSE_DEV_IOC_STRIPE_OPEN patch as implying that the mapping gets forwarded to the kernel through the backing id in the open() reply, which I think is how Amir had also interpreted it. I didn't like that the striping mappings got sent through an ioctl while the simple mappings didn't, but I think maybe the patch was not trying to suggest that and I had interpreted it too literally. I like the striping setup through an ioctl - I think it makes sense given that it is connection-level instead of inode-level. Thanks, Joanne [1] https://lore.kernel.org/linux-fsdevel/[email protected]/
