Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp3860438rwb; Sun, 20 Nov 2022 23:54:45 -0800 (PST) X-Google-Smtp-Source: AA0mqf5BJyjrlNOXFj5rivZwIFYHrx1pudQa8pPGac27rljmKMRY6+9Dcwder2UoFdQY/dLrB4Yl X-Received: by 2002:a17:906:4d8c:b0:7ae:ea7:2139 with SMTP id s12-20020a1709064d8c00b007ae0ea72139mr592869eju.319.1669017284879; Sun, 20 Nov 2022 23:54:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1669017284; cv=none; d=google.com; s=arc-20160816; b=fp68UAzYSV9VuUHRhNAaRdQybcvOHJwB1OUR2kwJ2e3wzL9ZqyIyzT+B0nkGKGbl28 TBVHHK5QaN9Donlepapl4RjLU4DMoRiL1yLv9XU+KV6eWOIe57m2Nf5SiARdsg+XUghg mfbHgTZX02vpGyxcsZaGP/AwqgO8bngBf9cmwwi2uueZAPOcTc6YqbAPrreJJpYRTMGM +ijNt9vZ62Ifb3i0DUvrLxO9KQqMK5MwwsoC00lDgEPKiUBG0Oe24L6P5V0IvzXNJCe2 ti3rksTMa6sf7L5FiG9SbLcgn2iWZJwiXKyh1N5xAXT/+8EPpIjZE6/FFgu6O1muecKw R9Aw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=ijaqg3+Ash+EpuX+C90QzheaoYoK/eHoLdMtkPSGwd8=; b=enb8ORtcv6sR117tmkG7LYRR+EagZBwY4n+jQm8kKQLnykgghdNTxrMdKofkNG4FOB UZq/nwL/HDpA2s5udKGIJMFuJhvaBWxhXb+u7yB4gA+pYmdTpZmk3+6Ko36ybC1F4GzL 2+zcdljXT/etHAqg84HCoccwUPu9BClOFEJfJJNkFvoO/TOuJMO4QYbCaTm6ppGoZMuW GmP8ja1tutrYjI4e+wENty/cBj5iJgl1zv3HUBTOvPEm2QF8+GKPlEE/L4mXqINW5v1F kNfdAYVA1CdT7beD4LXP+ofy4dcmZZKAWPgKBS3FSODtUULZodx5nOwFNIxAIQFU/hmh D3jw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id y7-20020a1709060a8700b0078e9ca562d8si7310439ejf.879.2022.11.20.23.54.19; Sun, 20 Nov 2022 23:54:44 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229675AbiKUHRM (ORCPT + 91 others); Mon, 21 Nov 2022 02:17:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:41502 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229379AbiKUHRK (ORCPT ); Mon, 21 Nov 2022 02:17:10 -0500 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C4E5213DFA; Sun, 20 Nov 2022 23:17:08 -0800 (PST) Received: by verein.lst.de (Postfix, from userid 2407) id 2E4FB68AA6; Mon, 21 Nov 2022 08:17:05 +0100 (CET) Date: Mon, 21 Nov 2022 08:17:04 +0100 From: Christoph Hellwig To: David Howells Cc: linux-afs@lists.infradead.org, Marc Dionne , Christoph Hellwig , Matthew Wilcox , Theodore Ts'o , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH] afs: Stop implementing ->writepage() Message-ID: <20221121071704.GC23882@lst.de> References: <166876785552.222254.4403222906022558715.stgit@warthog.procyon.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <166876785552.222254.4403222906022558715.stgit@warthog.procyon.org.uk> User-Agent: Mutt/1.5.17 (2007-11-01) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_HELO_NONE, SPF_NONE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 18, 2022 at 10:37:35AM +0000, David Howells wrote: > A hint flag is added to the writeback_control struct so that a filesystem > can say that the write is triggered by write_begin seeing a conflicting > write. This causes do_writepages() to do a single pass of the loop only. Not a huge fan of that, especially as write_begin is not really a method, but just an awkward hook in legacy write implementations. I'd much rather have a private pointer in the writeback_control and make the behavior implementation specific. It will need to be split into a separate patch with proper documentation and a CC to linux-mm. > (1) afs_write_back_from_locked_folio() could be called directly rather > than calling filemap_fdatawrite_wbc(), but that would avoid the > control group stuff that wbc_attach_and_unlock_inode() and co. seem to > do. Do I actually need to do this? That would be much preferred over the for_write_begin hack, given that write_begin really isn't a well defined method but a hacky hook for legacy write implementations. > (2) afs_writepages_region() has a loop in it to generate multiple writes. > do_writepages() also acquired a loop[2] which will also generate > multiple writes. Should I remove the loop from > afs_writepages_region() and leave it to the caller of ->writepages()? Dropping out of ->writpages inside a page does seem a bit problematic, so you probably want to keep the loop.