Miklos et. al.: Here are some specific questions related to the famfs port into fuse [1][2] that I hope Miklos (and others) can give me feedback on soonish. This work is active and serious, although you haven't heard much from me recently. I'm showing a famfs poster at Usenix FAST '25 this week [3]. I'm generally following the approach in [1] - in a famfs file system, LOOKUP is followed by GET_FMAP to retrieve the famfs file/dax metadata. It's tempting to merge the fmap into the LOOKUP reply, but this seems like an optimization to consider once basic function is established. Q: Do you think it makes sense to make the famfs fmap an optional, variable sized addition to the LOOKUP response? Whenever an fmap references a dax device that isn't already known to the famfs/fuse kernel code, a GET_DAXDEV message is sent, with the reply providing the info required to open teh daxdev. A file becomes available when the fmap is complete and all referenced daxdevs are "opened". Q: Any heartburn here? When GET_FMAP is separate from LOOKUP, READDIRPLUS won't add value unless it receives fmaps as part of the attributes (i.e. lookups) that come back in its response - since a READDIRPLUS that gets 12 files will still need 12 GET_FMAP messages/responses to be complete. Merging fmaps as optional, variable-length components of the READDIRPLUS response buffers could eventualy make sense, but a cleaner solution intially would seem to be to disable READDIRPLUS in famfs. But... * The libfuse/kernel ABI appears to allow low-level fuse servers that don't support READDIRPLUS... * But libfuse doesn't look at conn->want for the READDIRPLUS related capabilities * I have overridden that, but the kernel still sends the READDIRPLUS messages. It's possible I'm doing something hinky, and I'll keep looking for it. * When I just return -ENOSYS to READDIRPLUS, things don't work well. Still looking into this. Q: Do you know whether the current fuse kernel mod can handle a low-level fuse server that doesn't support READDIRPLUS? This may be broken. Q: If READDIRPLUS isn't actually optional, do you think the same attribute reply merge (attr + famfs fmap) is viable for READDIRPLUS? I'd very much like to do this part "later". Q: Are fuse lowlevel file systems like famfs expected to use libfuse and its message handling (particularly init), or is it preferred that they not do so? Seems a shame to throw away all that api version checking, but turning off READDIRPLUS would require changes that might affect other libfuse clients. Please advise... Note that the intended use cases for famfs generally involve large files rather than *many* files, so giving up READDIRPLUS may not matter very much, at least in the early going. I'm hoping to get an initial RFC patch set out in a few weeks, but these questions address [some of] the open issues that need to be [at least initially] resolved first. Regards, John [1] https://lore.kernel.org/linux-fsdevel/20241029011308.24890-1-john@xxxxxxxxxx/ [2] https://lwn.net/Articles/983105/ [3] https://www.usenix.org/conference/fast25/poster-session
