On Mon, Jul 20, 2026 at 5:44 AM John Groves <[email protected]> wrote: > > From: John Groves <[email protected]> > > This has been quite a gauntlet so far. Some requests were made but eventually > ruled out (e.g. using BPF for fault handling).
I'm sorry John, but this patch set is not what I was hoping to see. I don't know if we are miscommunicating or if it is something else. I will try to do my best to explain again. I say miscommunication when looking at your comment in reply to [1]: "First, a scope check. This patch touches only the daxdev registration - GET_FMAP, struct fuse_famfs_fmap_header, and the simple/interleave extent structs in include/uapi/linux/fuse.h are untouched. I'm reading that as tacit agreement to GET_FMAP and its ABI. Can you confirm? If so the large piece is settled and this is really just about how a daxdev gets registered." This was a wrong assumption on your part, it was NOT confirmed and I even responded to it with a mini tantrum. I feel that you may have not gotten Miklos' second patch [2] at all, because you have not responded to it. Maybe because it was sent only to your work email? > > Concrete requests (demands?) from the fuse community included the following: > - Pass daxdevs into the kernel via an ioctl rather than a new fuse > message/response Look at this patch by Miklos: [1] https://lore.kernel.org/fuse-devel/[email protected]/ Look more closely at the diffstat: 7 files changed, 123 insertions(+), 294 deletions(-) It's not about this ioctl, it's about infrastructure reuse. It's about the fact that there is NOTHING special about dax_devlist; and no reason not to manage it via backing_files_map. The reason you stated was that you want userspace to determine the daxdev_index/backing_id - fine, no problem - this is why I asked that you pass it the desired backing_id in the ioctl. In fact I think that all fuse backing_ids would be better assigned by user space so the extension of padding => backing_id is not unique to famfs. And the best part is that this request requires no changes to your userspace. You already bite the bullet and maintain the new/old uapi but changing the kernel implementation does not require this burden from you, so to be honest I really don't understand why you did not follow Miklos' suggestion. > - Lose the famfs interleaved extent format. I have complied with this request. > It makes some things worse, but we'll discuss that later. > I am really not aware of a request to lose the interleaved extent format. How can this patch [2] from Miklos which reimplements this format as a generic uapi be mistaken for a request to lose this format? > There has also been a desire from the fuse community for famfs to use an > experimental implementation of virtual backing-devs from Darrick. I'm leaving > this out as a potential future optimization - although Darrick has announced > that he (and $employer) intend to abandon that work, so it's not clear whether > that will become viable. Forgive me John, but I am having a hard time following the logic of this statement. How are Darrick's future plans about fuse iomap even remotely related? In this patch Miklos has ALREADY IMPLEMENTED "striped "virtual" backing devices (idea from Darrick)" [2] https://lore.kernel.org/linux-fsdevel/[email protected]/ An idea does not die when employers change priorities. The diffstat is also impressive: 6 files changed, 219 insertions(+), 300 deletions(-) Especially when considering the fact that the insertions are generic code that could be useful to fuse passthrough regardless of famfs. Let me recap the former review requests as I understand them: 1. Use ioctl instead of GET_DAXDEV 2. Use backing files infra for daxdev table 3. Use ioctl instead of GET_FMAP 4. Use backing files infra for fmaps Request #1 was fulfilled in the v11 patch set. Other requests were not fulfilled and with no explanation why, not one that I could find anyway. Perhaps requests 2-4 were lost in the spam folder and/or lost in translation, so I will repeat my question from review of [1]: Are there any other *technical* problems that you can point out with the patches that Miklos posted (including FUSE_DEV_IOC_STRIPE_OPEN)? Thanks, Amir.
