Re: [PATCH V11 0/9] famfs: port into fuse

[Miklos Szeredi]

On Wed, 22 Jul 2026 at 16:43, Joanne Koong <joannelkoong@xxxxxxxxx> 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.

Maybe the striping setup can also be done with a notification.  The
original reason for doing  FUSE_DEV_IOC_BACKING_OPEN() out of band was
to prevent security issues with writing an fd with plain write()
syscalls.  This issue does not affect io-uring, which does not use
write and so the ioctl can be completely eliminated.  But that's
another story..

Thanks,
Miklos