From: David Howells <dhowells@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: dhowells@redhat.com, Trond Myklebust <trondmy@hammerspace.com>,
Anna Schumaker <anna.schumaker@netapp.com>,
Steve French <sfrench@samba.org>,
Dominique Martinet <asmadeus@codewreck.org>,
v9fs-developer@lists.sourceforge.net,
CIFS <linux-cifs@vger.kernel.org>,
Trond Myklebust <trond.myklebust@hammerspace.com>,
"open list:NFS, SUNRPC, AND..." <linux-nfs@vger.kernel.org>,
linux-cachefs@redhat.com, Dave Wysochanski <dwysocha@redhat.com>,
Shyam Prasad N <nspmangalore@gmail.com>,
Jeff Layton <jlayton@redhat.com>,
Matthew Wilcox <willy@infradead.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-afs@lists.infradead.org, ceph-devel@vger.kernel.org,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 00/10] fscache: Replace and remove old I/O API
Date: Fri, 29 Oct 2021 19:51:34 +0100 [thread overview]
Message-ID: <1891411.1635533494@warthog.procyon.org.uk> (raw)
In-Reply-To: <CAHk-=wg_C6V_S+Aox5Fn7MuFe13ADiRVnh6UcvY4WX9JjXn3dg@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> But:
>
> > However, if you would rather I just removed all of fscache and (most of[*])
> > cachefiles, that I can do.
>
> I assume and think that if you just do that part first, then the
> "convert to netfslib" of afs and ceph at that later stage will mean
> that the fallback code will never be needed?
The netfslib coversions for afs and ceph are already in your tree and I have a
patch here to do that for 9p (if you're willing to take that in the upcoming
merge window?).
The issue is cifs[*] and nfs. I could leave caching in those disabled,
pending approved patches for those filesystems. This would mean that I
wouldn't need the fallback code.
An alternative is that I could move the "fallback" code into fs/nfs/fscache.c
and fs/cifs/fscache.c if that would be easier and merge it into the functions
there. The problem will come when the cache wants to do I/O in larger units
than page size to suit its own block size[**].
David
[*] As it happens, it turns out that cifs seems to have a bug in it that
causes the entire cache for a superblock to be discarded each time that
superblock is mounted.
[**] At some point the cache *has* to start keeping track of what data it is
holding rather than relying on bmap/SEEK_DATA/SEEK_HOLE to get round the
extent-bridging problem. I'm trying to take a leaf out of the book of other
caching filesystems and use larger block sizes (e.g. 256K) to reduce the
overhead of cache metadata.
prev parent reply other threads:[~2021-10-29 18:52 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-29 14:08 [PATCH v4 00/10] fscache: Replace and remove old I/O API David Howells
2021-10-29 14:09 ` [PATCH v4 01/10] fscache: Generalise the ->begin_read_operation method David Howells
2021-10-29 14:09 ` [PATCH v4 02/10] fscache: Fix fscache_cookie_enabled() to handle NULL cookie David Howells
2021-10-29 14:09 ` [PATCH v4 03/10] cachefiles: Always indicate we should fill a post-EOF page with zeros David Howells
2021-10-29 14:10 ` [PATCH v4 04/10] fscache: Implement a fallback I/O interface to replace the old API David Howells
2021-10-29 14:10 ` [PATCH v4 05/10] nfs: Move to using the alternate fallback fscache I/O API David Howells
2021-10-29 14:10 ` [PATCH v4 06/10] 9p: Convert to using the netfs helper lib to do reads and caching David Howells
2021-10-29 14:10 ` [PATCH v4 07/10] cifs: Move to using the alternate fallback fscache I/O API David Howells
2021-10-29 14:11 ` [PATCH v4 08/10] fscache: Remove the old " David Howells
2021-10-29 14:11 ` [PATCH v4 09/10] fscache: Remove stats that are no longer used David Howells
2021-10-29 14:11 ` [PATCH v4 10/10] fscache: Update the documentation to reflect I/O API changes David Howells
2021-10-29 16:49 ` [PATCH v4 00/10] fscache: Replace and remove old I/O API Linus Torvalds
2021-10-29 17:55 ` David Howells
2021-10-29 18:17 ` Linus Torvalds
2021-10-29 18:51 ` David Howells [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1891411.1635533494@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=anna.schumaker@netapp.com \
--cc=asmadeus@codewreck.org \
--cc=ceph-devel@vger.kernel.org \
--cc=dwysocha@redhat.com \
--cc=jlayton@redhat.com \
--cc=linux-afs@lists.infradead.org \
--cc=linux-cachefs@redhat.com \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=nspmangalore@gmail.com \
--cc=sfrench@samba.org \
--cc=torvalds@linux-foundation.org \
--cc=trond.myklebust@hammerspace.com \
--cc=trondmy@hammerspace.com \
--cc=v9fs-developer@lists.sourceforge.net \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).