> > 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... > imo, I don't see any benefits from using a custom-written library instead of libfuse. I think there'd end up being a lot of overlap between the two and wouldn't be worth the hassle. > 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. > Looking forward to reading your RFC patch. Thanks, Joanne > > 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
