From: Anna Schumaker <Anna.Schumaker@xxxxxxxxxx>
The main motivation for this patchset is fixing generic/091 and
generic/263 with READ_PLUS. These tests appear to be failing due to
files getting modified in the middle of reply encoding. Attempts to lock
the file for the entire encode result in a deadlock, since llseek() and
read() both need the file lock.
The solution is to read everything from disk at once, and then check if
each buffer page is all zeroes or not. As a bonus, this lets us support
READ_PLUS hole segments on filesystems that don't track sparse files.
Additionally, this also solves the performance issues I hit when testing
using btrfs on a virtual machine.
I created a wiki page with the results of my performance testing here:
https://wiki.linux-nfs.org/wiki/index.php/Read_Plus_May_2022
These should probably have some soak time in linux-next, so let's target
them for the Linux 5.20 (6.0?) merge window rather than rushing to get
them into 5.19. As far as ordering goes, these patches should probably
go in before the related client changes as the client will also be
changed to make use of the xdr_stream_move_segment() function.
Thoughts?
Anna
Anna Schumaker (6):
SUNRPC: Introduce xdr_stream_move_segment()
SUNRPC: Introduce xdr_encode_double()
SUNRPC: Introduce xdr_buf_trim_head()
SUNRPC: Introduce xdr_buf_nth_page_address()
SUNRPC: Export xdr_buf_pagecount()
NFSD: Repeal and replace the READ_PLUS implementation
fs/nfsd/nfs4xdr.c | 202 +++++++++++++++++++------------------
include/linux/sunrpc/xdr.h | 6 ++
net/sunrpc/xdr.c | 102 +++++++++++++++++++
3 files changed, 210 insertions(+), 100 deletions(-)
--
2.36.1
