On Fri, Jul 17, 2020 at 04:19:25PM +0100, David Howells wrote: > J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > > Say I had a hypothetical, err, friend, who hadn't been following that > > FS-Cache work--could you summarize the advantages it bring us? > > https://lore.kernel.org/linux-nfs/159465784033.1376674.18106463693989811037.stgit@xxxxxxxxxxxxxxxxxxxxxx/T/#t > > - Makes the caching code a lot simpler (~2400 LoC removed, ~1000 LoDoc[*] > removed at the moment from fscache, cachefiles and afs). > > - Stops using bmap to work out what data is cached. This isn't reliable with > modern extend-based filesystems. A bitmap of cached granules is saved in > an xattr instead. > > - Uses async DIO (kiocbs) to do I/O to/from the cache rather than using > buffered writes (kernel_write) and pagecache snooping for read (don't ask). > > - A lot faster and less CPU intensive as there's no page-to-page copying. > > - A lot less VM pressure as it doesn't have duplicate pages in the backing > fs that aren't really accounted right. > > - Uses tmpfiles+link to better handle invalidation. It will at some point > hopefully employ linkat(AT_LINK_REPLACE) to effect cut-over on disk rather > than unlink,link. Thanks!--b. > David > > [*] The upstream docs got ReSTified, so the doc patches I have are now useless > and need reworking:-(. -- Linux-cachefs mailing list Linux-cachefs@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/linux-cachefs
