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=-3.6 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no 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 9B166C4338F for ; Thu, 5 Aug 2021 22:12:17 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 2799C6112F for ; Thu, 5 Aug 2021 22:12:17 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.1 mail.kernel.org 2799C6112F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=infradead.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=kvack.org Received: by kanga.kvack.org (Postfix) id 5B6466B006C; Thu, 5 Aug 2021 18:12:16 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 53E196B0071; Thu, 5 Aug 2021 18:12:16 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3DE888D0001; Thu, 5 Aug 2021 18:12:16 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0120.hostedemail.com [216.40.44.120]) by kanga.kvack.org (Postfix) with ESMTP id 1DEDE6B006C for ; Thu, 5 Aug 2021 18:12:16 -0400 (EDT) Received: from smtpin36.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id BA64F180ACF14 for ; Thu, 5 Aug 2021 22:12:15 +0000 (UTC) X-FDA: 78442426230.36.A8EFABB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 425F15041719 for ; Thu, 5 Aug 2021 22:12:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=RvO+6JeVpLxlPcNmPsjLLYdjB15f9d7yagNnMlUscyM=; b=JmZQe8YwHGdxpbt0TwH//rA7bp HfAA5mzWQ300vIpQYo2arTXyklr5l76dKVELRLgAZnUKxXoRc+QEJSbaJuD0GoNpSfCd/Tm0UBMuE 8SlOk735EbFz/87qkcy75AdIYWBzf/6Pu9MY7CX3ueVVY4JMora1+0oRcuu8osroUGfT0mXjfvMK6 YRKger+O0AuVg9xmmLmzYUXKEtKW1DDQMgyAYZHjWr1kcBaMhMeG32BSAx4/3o6o/iRQtgZutc3wC Ppbf+HBE58BXsebQaFSh/F53V7A49MoL26n7Xo3oyaKsNZoU5Zwaw2sdDXexB/tn2REY4APSX99IZ UDs7r7iQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1mBla0-007ZDJ-Ph; Thu, 05 Aug 2021 22:11:12 +0000 Date: Thu, 5 Aug 2021 23:11:08 +0100 From: Matthew Wilcox To: Linus Torvalds Cc: David Howells , Anna Schumaker , Trond Myklebust , Jeff Layton , Steve French , Dominique Martinet , Mike Marshall , Miklos Szeredi , Shyam Prasad N , linux-cachefs@redhat.com, linux-afs@lists.infradead.org, "open list:NFS, SUNRPC, AND..." , CIFS , ceph-devel@vger.kernel.org, v9fs-developer@lists.sourceforge.net, devel@lists.orangefs.org, Linux-MM , linux-fsdevel , Linux Kernel Mailing List Subject: Re: Canvassing for network filesystem write size vs page size Message-ID: References: <1017390.1628158757@warthog.procyon.org.uk> <1170464.1628168823@warthog.procyon.org.uk> <1186271.1628174281@warthog.procyon.org.uk> <1219713.1628181333@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam03 X-Rspamd-Queue-Id: 425F15041719 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=JmZQe8Yw; dmarc=none; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org X-Stat-Signature: ehsst3othr4hr3ee9fncpu3kta6ta7dg X-HE-Tag: 1628201534-715956 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Thu, Aug 05, 2021 at 10:27:05AM -0700, Linus Torvalds wrote: > On Thu, Aug 5, 2021 at 9:36 AM David Howells wrote: > > Some network filesystems, however, currently keep track of which byte ranges > > are modified within a dirty page (AFS does; NFS seems to also) and only write > > out the modified data. > > NFS definitely does. I haven't used NFS in two decades, but I worked > on some of the code (read: I made nfs use the page cache both for > reading and writing) back in my Transmeta days, because NFSv2 was the > default filesystem setup back then. > > See fs/nfs/write.c, although I have to admit that I don't recognize > that code any more. > > It's fairly important to be able to do streaming writes without having > to read the old contents for some loads. And read-modify-write cycles > are death for performance, so you really want to coalesce writes until > you have the whole page. I completely agree with you. The context you're missing is that Dave wants to do RMW twice. He doesn't do the delaying SetPageUptodate dance. If the write is less than the whole page, AFS, Ceph and anybody else using netfs_write_begin() will first read the entire page in and mark it Uptodate. Then he wants to track which parts of the page are dirty (at byte granularity) and send only those bytes to the server in a write request. So it's worst of both worlds; first the client does an RMW, then the server does an RMW (assuming the client's data is no longer in the server's cache. The NFS code moves the RMW from the client to the server, and that makes a load of sense. > That said, I suspect it's also *very* filesystem-specific, to the > point where it might not be worth trying to do in some generic manner. It certainly doesn't make sense for block filesystems. Since they can only do I/O on block boundaries, a sub-block write has to read in the surrounding block, and once you're doing that, you might as well read in the whole page. Tracking sub-page dirty bits still makes sense. It's on my to-do list for iomap. > [ goes off and looks. See "nfs_write_begin()" and friends in > fs/nfs/file.c for some of the examples of these things, althjough it > looks like the code is less aggressive about avoding the > read-modify-write case than I thought I remembered, and only does it > for write-only opens ] NFS is missing one trick; it could implement aops->is_partially_uptodate and then it would be able to read back bytes that have already been written by this client without writing back the dirty ranges and fetching the page from the server. Maybe this isn't an important optimisation.