Hi, On Mon, Jan 31, 2022 at 09:06:13PM +0000, David Howells wrote: > I've been working on a library (in fs/netfs/) to provide network filesystem > support services, with help particularly from Jeff Layton. The idea is to > move the common features of the VM interface, including request splitting, > operation retrying, local caching, content encryption, bounce buffering and > compression into one place so that various filesystems can share it. > > This also intersects with the folios topic as one of the reasons for this now > is to hide as much of the existence of folios/pages from the filesystem, > instead giving it persistent iov iterators to describe the buffers available > to it. > > It could be useful to get various network filesystem maintainers together to > discuss it and how to do parts of it and how to roll it out into more > filesystems if it suits them. This might qualify more for a BoF session than > a full FS track session. We are interested in fscache on-demand read use cases, assuming fscache plans to be a generic filesystem caching framework besides just caching network data [1] [2] [3]. So fscache is still preferred to us instead of re-inventing another cache-managing wheel like this and the modification seems very limited. We hope this feature could be upstreamed this year in order to benefit the whole container image ecosystem. Jeffle will post v3 after lunar new year holidays. I also think more potential possibility, such as fscache over iomap interface or similiar, since iomap is also another powerful I/O framework. IMHO, at least having a unique interface in the long term may be a good idea for all fses. > > Further, discussion of designing a more effective cache backend could be > useful. I'm thinking along the lines of something that can store its data on > a single file (or a raw blockdev) with indexing along the lines of what > filesystem drivers such as openafs do. With my own limited understanding, I'm not sure how one single huge file works quite well (assuming appending write is needed comparing with raw blockdev). Or you may need some fallocate() to allocate space in bulk if there is not enough caching space, which is much like what now databases do. [1] https://lore.kernel.org/r/20220118131216.85338-1-jefflexu@xxxxxxxxxxxxxxxxx [2] https://lore.kernel.org/r/Yeeye2AUZITDsdh8@B-P7TQMD6M-0146.local [3] https://lore.kernel.org/r/8f73d28e-db30-f2e4-0143-9d75c4b13087@xxxxxxxxxxxxxxxxx Thanks, Gao Xiang > > David >