On Fri, Aug 15, 2025 at 10:06:01AM -0500, John Groves wrote: > On 25/08/14 11:20AM, Darrick J. Wong wrote: > > On Thu, Aug 14, 2025 at 04:36:57PM +0200, Miklos Szeredi wrote: > > > On Thu, 14 Aug 2025 at 15:36, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > > > > > > I'm still hoping some common ground would benefit both interfaces. > > > > Just not sure what it should be. > > > > > > Something very high level: > > > > > > - allow several map formats: say a plain one with a list of extents > > > and a famfs one > > > > Yes, I think that's needed. > > Agreed > > > > > > - allow several types of backing files: say regular and dax dev > > > > "block device", for iomap. > > > > > - querying maps has a common protocol, format of maps is opaque to this > > > - maps are cached by a common facility > > > > I've written such a cache already. :) > > I guess I need to take a look at that. Can you point me to the right place? > > > > > > - each type of mapping has a decoder module > > > > I don't know that you need much "decoding" -- for famfs, the regular > > mappings correspond to FUSE_IOMAP_TYPE_MAPPED. The one goofy part is > > the device cookie in each IO mapping: fuse-iomap maps each block device > > you give it to a device cookie, so I guess famfs will have to do the > > same. > > > > OTOH you can then have a famfs backed by many persistent memory > > devices. > > That's handled in the famfs fmaps already. When an fmap is ingested, > if it references any previously-unknown daxdevs, they get retrieved > (FUSE_GET_DAXDEV). > > Oversimplifying a bit, I assume that famfs fmaps won't really change, > they'll just be retrieved by a more flexible method and be preceded > by a header that identifies the payload as a famfs fmap. <nod> Well, I suppose fmaps aren't supposed to change much, but I get the strong sense that Miklos would rather we both use the FUSE_DEV_IOC_BACKING_OPEN interface... > > > > > - each type of backing file has a module for handling I/O > > > > > > Does this make sense? > > > > More or less. > > I'm nervous about going for too much generalization too soon here, > but otherwise yeah. ...and I've tried to make it simple for famfs to pick up the interface. >From the new fuse_backing_open: /* * Each _backing_open function should either: * * 1. Take a ref to fb if it wants the file and return 0. * 2. Return 0 without taking a ref if the backing file isn't needed. * 3. Return an errno explaining why it couldn't attach. * * If at least one subsystem bumps the reference count to open it, * we'll install it into the index and return the index. If nobody * opens the file, the error code will be passed up. EPERM is the * default. */ passthrough_res = fuse_passthrough_backing_open(fc, fb); iomap_res = fuse_iomap_backing_open(fc, fb); if (refcount_read(&fb->count) < 2) /* drop the fuse_backing and return one of the res */ So all your famfs_backing_open function has to do is check that fb->file points to a pmem device. If so, it sets fb->famfs = 1 and bumps the fb->count refcount. Full code here: https://git.kernel.org/pub/scm/linux/kernel/git/djwong/xfs-linux.git/log/?h=fuse-iomap-attrs_2025-08-19 I'll let the build robots find any facepalm problems and post this whole series tomorrow. > > > This doesn't have to be implemented in one go, but for example > > > GET_FMAP could be renamed to GET_READ_MAP with an added offset and > > > size parameter. For famfs the offset/size would be set to zero/inf. > > > I'd be content with that for now. > > > > I'll try to cough up a RFC v4 next week. > > Darrick, let's try to chat next week to compare notes. > > Based on this thinking, I will keep my rework of GET_FMAP to a minimum > since that will likely be a new shared message/response. I think that > part can be merged later in the cycle... <nod> --D
