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. > - 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. :) > - 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. > - each type of backing file has a module for handling I/O > > Does this make sense? More or less. > 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. --D > Thanks, > Miklos > > > > > Thanks, > > Miklos >
