Re: [LSF/MM/BPF TOPIC] Netfs support library

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> 



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [NTFS 3]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [NTFS 3]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux