From: David Howells <firstname.lastname@example.org>
Cc: email@example.com, Matthew Wilcox <firstname.lastname@example.org>,
Anna Schumaker <email@example.com>,
Trond Myklebust <firstname.lastname@example.org>,
Steve French <email@example.com>,
Dominique Martinet <firstname.lastname@example.org>,
Jeff Layton <email@example.com>,
David Wysochanski <firstname.lastname@example.org>,
Alexander Viro <email@example.com>,
Subject: Upcoming for next merge window: fscache and netfs lib
Date: Fri, 05 Feb 2021 17:02:14 +0000 [thread overview]
Message-ID: <firstname.lastname@example.org> (raw)
To apprise you in advance, I'm intending to submit a pull request for a
partial modernisation of the fscache I/O subsystem, which can be found here:
The main parts of it are:
(1) Institute a helper library for network filesystems. The first stage of
this handles ->readpage(), ->readahead() and part of ->write_begin() on
behalf of the netfs, requiring the netfs to provide a vector to perform a
read to some part of an inode.
This allows handling of the following to be (at least partially) moved
out of all the network filesystems and consolidated in one place:
- changes in VM vectors (Matthew Wilcox's Grand Plans™;-)
- transparent huge page support
- shaping of reads
- readahead expansion
- fs alignment/granularity (ceph, pnfs)
- cache alignment/granularity
- slicing of reads
- keeping multiple read in flight } Steve French would like
- multichannel distribution } but for the future
- multiserver distribution (ceph, pnfs)
- stitching together reads from the cache and reads from the network
- saving data read from the server into the cache
- retry/reissue handling
- fallback after cache failure
- short reads
- fscrypt data decryption (Jeff Layton is considering for the future)
(2) Add an alternate cache I/O API for use with the netfs lib that makes use
of kiocbs in the cache to do direct I/O between the cache files and the
This is intended to replace the current I/O API that calls the backing fs
readpage op and than snooping the wait queues for completion to read and
using vfs_write() to write. It wasn't possible to do in-kernel DIO when
I first wrote cachefiles - and this makes it a lot simpler and more
robust (and uses a lot less memory).
(3) Add an ITER_XARRAY iov_iter that allows I/O iteration to be done on an
xarray of pinned pages (such as inode->i_mapping->i_pages), thereby
avoiding the need to allocate a bvec array to represent this.
This is used to present a set of netfs pages to the cache to do DIO on
and is also used by afs to present netfs pages to sendmsg. It could also
be used by unencrypted cifs to pass the pages to the TCP socket it uses
(if it's doing TCP) and my patch for 9p (which isn't included here) can
make use of it.
(4) Make afs use the above. It passes the same xfstests (and has the same
failures) as the unpatched afs client.
(5) Make ceph use the above (I've merged a branch from Jeff Layton for this).
This also passes xfstests.
Dave Wysochanski has a patch series for nfs. Normal nfs works fine and passes
various tests, but it turned out pnfs has a problem - pnfs does splitting of
requests itself and sending them to various places, but it needs to cooperate
more closely with netfs over this. He's working on this.
I've given Dominique Martinet a patch for 9p and Steve French a partial patch
for cifs, but neither of those is going to be ready this merge window either.
Assuming you're willing to take this, should I submit one pull request for the
combined lot, or should I break it up into smaller requests (say with a
separate request from Jeff for the ceph stuff).
If we can get the netfs lib in this merge window, that simplifies dealing with
nfs and cifs particularly as the changes specific to those can go through the
reply other threads:[~2021-02-05 19:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).