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