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. 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
