On 26/07/22 12:46PM, Miklos Szeredi wrote: > On Mon, 20 Jul 2026 at 12:07, Amir Goldstein <[email protected]> wrote: > > > 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. > > Right, so I suggest to just reuse FUSE_DEV_IOC_BACKING_OPEN and add > two flags: one to enable user supplied backing ID and the other to > indicate that fd refers to DAX device. The changes to do compared to > the current patchset are quite minimal. > > > 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. > > Code reuse is also important, but I understand John's position to want > to separate famfs from existing codebase as much as possible. And > because this is an implementation detail I don't want to make this a > show stopper. We can easily fix it later. > > > > - 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? > > Let's not care. We can easily add this later if famfs (or any other > use case) decides to want this after all. > > Making the initial patchset smaller is win in any case. > > > Let me recap the former review requests as I understand them: > > > > 1. Use ioctl instead of GET_DAXDEV > > This is done, just need to reuse the existing ioctl instead of add a > new one with the same semantics (okay not true because of the fixed > backing ID extension...) > > > 2. Use backing files infra for daxdev table > > Leave this later. > > > 3. Use ioctl instead of GET_FMAP > > Not sure we agreed to use an ioctl for extent mapping. What we did > agree on was to use a generic interface that doesn't have anything > famfs specific in it. > > John, can you please also look at review comments provided by Sashiko? > > Thanks, > Miklos
This a quick acknowledgment that I appreciate your reply Miklos. I'll respond to individual points as soon as I can without rushing. Re: Sashiko - of course! The series has been through /kreview in Chris' review-prompts repo. Weird that I didn't get any email directly from Sashiko this time, but I know how to get to it online. I will make this high-level comment: After reading Amir's initial reply, I concluded that the requested changes push famfs past the breaking point, and therefore the only way to keep famfs suitable for its intended usage is to pivot back to standalone. I do think that may be best all-around for fuse, famfs and Linux. I don't see any way famfs makes fuse better - it's a very specialized pattern that doesn't fit in a passthrough-filesystem or block-filesystem shaped hole. And I don't think it can comply with the "nothing famfs-specific in GET_FMAP" objective. If famfs is standalone, it can only ever affect customers who use it, and it cannot be used as a general purpose file system. When famfs is in fuse, it's mashed up with code for hundreds or thousands of other use cases. That's not a win from a risk management standpoint, and it doesn't make famfs better - certainly not in any way that would mitigate adding a lot of state / complexity / baggage to famfs. In good faith, John
