From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-11.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B4508C433DB for ; Fri, 5 Feb 2021 19:44:15 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 4BF0D64F05 for ; Fri, 5 Feb 2021 19:44:15 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230035AbhBESBp (ORCPT ); Fri, 5 Feb 2021 13:01:45 -0500 Received: from us-smtp-delivery-124.mimecast.com ([216.205.24.124]:22964 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233217AbhBEPWo (ORCPT ); Fri, 5 Feb 2021 10:22:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1612544551; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding; bh=2q18CzBcxJvAu8Vj/9Xv+8eYOiYLfIpMMBqp/lRA8Jc=; b=U72yp1HgA9Cwsen4QvMB9seFW1rnkekQDuVz1X4t7m80hOvQ79/4oeStIDub+EbCGn/b/v 73Gyur8BCA7x3lGaJq6aL49VIx2wxhar09Oy+ckSUWVRALQsEJ08b9KKKwDO3v3vQvYgMz DupvEzFMgYiD9fJYiUwiXdDMhWrUBWA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-511-Ui2ao1J7MTWjBnKX2-SeOQ-1; Fri, 05 Feb 2021 12:02:24 -0500 X-MC-Unique: Ui2ao1J7MTWjBnKX2-SeOQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id AD1AE100A625; Fri, 5 Feb 2021 17:02:21 +0000 (UTC) Received: from warthog.procyon.org.uk (ovpn-115-23.rdu2.redhat.com [10.10.115.23]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1D00E1A353; Fri, 5 Feb 2021 17:02:14 +0000 (UTC) Organization: Red Hat UK Ltd. Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 From: David Howells To: torvalds@linux-foundation.org cc: dhowells@redhat.com, Matthew Wilcox , Anna Schumaker , Trond Myklebust , Steve French , Dominique Martinet , Jeff Layton , David Wysochanski , Alexander Viro , ceph-devel@vger.kernel.org, linux-afs@lists.infradead.org, linux-cachefs@redhat.com, linux-cifs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org, v9fs-developer@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Upcoming for next merge window: fscache and netfs lib MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Fri, 05 Feb 2021 17:02:14 +0000 Message-ID: <2522190.1612544534@warthog.procyon.org.uk> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org Hi Linus, 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: https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/= ?h=3Dfscache-next 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 perfor= m 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=E2=84=A2;-) - transparent huge page support - shaping of reads - readahead expansion - fs alignment/granularity (ceph, pnfs) - cache alignment/granularity - slicing of reads - rsize - 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 u= se of kiocbs in the cache to do direct I/O between the cache files and the netfs pages. 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 a= nd using vfs_write() to write. It wasn't possible to do in-kernel DIO wh= en 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 a= lso 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 thi= s). This also passes xfstests. Dave Wysochanski has a patch series for nfs. Normal nfs works fine and pas= ses 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 coopera= te 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 pat= ch for cifs, but neither of those is going to be ready this merge window eithe= r. -~- 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 w= ith nfs and cifs particularly as the changes specific to those can go through t= he maintainer trees. Thanks, David