Jeffle Xu <jefflexu@xxxxxxxxxxxxxxxxx> wrote: > The following issues still need further discussion. Thanks for your time > and patience. > > 1. I noticed that there's refactoring of netfs library[1], > ... > [1] https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=netfs-lib Yes. I'm working towards getting netfslib to do handling writes and dio as well as reads, along with content crypto/compression, and the idea I'm aiming towards is that you just point your address_space_ops at netfs directly if possible - but it's going to require its own context now to manage pending writes. See my netfs-experimental branch for more of that - it's still a work in progress, though. Btw, you could set rreq->netfs_priv in ->init_rreq() rather than passing it in to netfs_readpage(). > 2. The current implementation will severely conflict with the > refactoring of netfs library[1][2]. The assumption of 'struct > netfs_i_context' [2] is that, every file in the upper netfs will > correspond to only one backing file. While in our scenario, one file in > erofs can correspond to multiple backing files. That is, the content of > one file can be divided into multiple chunks, and are distrubuted over > multiple blob files, i.e. multiple backing files. Currently I have no > good idea solving this conflic. I can think of a couple of options to explore: (1) Duplicate the cachefiles backend. You can discard a lot of it, since a much of it is concerned with managing local modifications - which you're not going to do since you have a R/O filesystem and you're looking at importing files into the cache externally to the kernel. I would suggest looking to see if you can do the blob mapping in the backend rather than passing the offset down. Maybe make the cookie index key hold the index too, e.g. "/path/to/file+offset". Btw, do you still need cachefilesd for its culling duties? (2) Do you actually need to go through netfslib? Might it be easier to call fscache_read() directly? Have a look at fs/nfs/fscache.c > Besides there are still two quetions: > - What's the plan of [1]? When is it planned to be merged? Hopefully next merge window, but that's going to depend on a number of things. > - It seems that all upper fs using fscache is going to use netfs API, > while the APIs like fscache_read_or_alloc_page() are deprecated. Is > that true? fscache_read_or_alloc_page() is gone completely. You don't have to use the netfs API. You can talk to fscache directly, doing DIO from the cache to an xarray-class iov_iter constructed from your inode's pagecache. netfslib provides/will provide a number of services, such as multipage folios, transparent caching, crypto, compression and hiding the existence of pages/folios from the filesystem as entirely as possible. However, you already have some of these implemented on top of iomap for the blockdev interface, it would appear. David
