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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B22CAC19F2D for ; Thu, 11 Aug 2022 05:58:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 9F5218E0002; Thu, 11 Aug 2022 01:58:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9A4DF8E0001; Thu, 11 Aug 2022 01:58:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 893828E0002; Thu, 11 Aug 2022 01:58:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 7A3C68E0001 for ; Thu, 11 Aug 2022 01:58:17 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4F96640705 for ; Thu, 11 Aug 2022 05:58:17 +0000 (UTC) X-FDA: 79786256634.18.BB95B77 Received: from verein.lst.de (verein.lst.de [213.95.11.211]) by imf18.hostedemail.com (Postfix) with ESMTP id 99C211C00A1 for ; Thu, 11 Aug 2022 05:58:16 +0000 (UTC) Received: by verein.lst.de (Postfix, from userid 2407) id 2AF2968AA6; Thu, 11 Aug 2022 07:58:12 +0200 (CEST) Date: Thu, 11 Aug 2022 07:58:11 +0200 From: Christoph Hellwig To: Matthew Wilcox Cc: Johannes Weiner , Christoph Hellwig , Mel Gorman , Jan Kara , Bob Peterson , Andreas Gruenbacher , "Darrick J. Wong" , Damien Le Moal , Naohiro Aota , Vlastimil Babka , Johannes Thumshirn , cluster-devel@redhat.com, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: remove iomap_writepage v2 Message-ID: <20220811055811.GA12359@lst.de> References: <20220719041311.709250-1-hch@lst.de> <20220728111016.uwbaywprzkzne7ib@quack3> <20220729092216.GE3493@suse.de> <20220729141145.GA31605@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2007-11-01) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1660197497; h=from:from:sender: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: in-reply-to:in-reply-to:references:references; bh=JJKpJkz4J31Xc1FOEek4ONIECUiUyXQKOZDozSH+Hu8=; b=RGQGdde1lcCfrhdgnPaa/LvKDr19NygBi51Us89rOIuJoYtx1BQbW8g6jIb2Ba+4qcWmYH jCZMdbf1zjmxBpSUdmRr6q1OPA4vV9jqlZ/o40OnROK3laOXavtArjH3meiKZdOtFX61sU /ciyQHlhpDE7U42Y304tXaYKw+MmG4M= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=none (imf18.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1660197497; a=rsa-sha256; cv=none; b=mI7445nUCqk81CXIqlUEAvompi4ssjfWuCXvIlUowegZDJkTwuQIUONqNMsA0/oVIsJrFf mjEhAg8X8fTeTk22fiUQxCcSlUNQWwjCGaqtpN4fJVdx9R8xnpx1sdfA67Ml6cBeyLACD0 yJq+RdYwdn+RnuebkYKyJYYkHRE/jLs= X-Stat-Signature: 78yznqqkcbddqq53gzjnz4g9ks4sk4fr X-Rspamd-Queue-Id: 99C211C00A1 Authentication-Results: imf18.hostedemail.com; dkim=none; spf=none (imf18.hostedemail.com: domain of hch@lst.de has no SPF policy when checking 213.95.11.211) smtp.mailfrom=hch@lst.de; dmarc=none X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1660197496-871139 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 Wed, Aug 10, 2022 at 09:43:58PM +0100, Matthew Wilcox wrote: > To avoid duplicating work with you or Christoph ... it seems like the > plan is to kill ->writepage entirely soon, so there's no point in me > doing a sweep of all the filesystems to convert ->writepage to > ->write_folio, correct? While I won't commit to concrete definition of "soon" I think that is the general plan, and I don't think converting ->writepage to ->write_folio is needed. > I assume the plan for filesystems which have a writepage but don't have > a ->writepages (9p, adfs, affs, bfs, ecryptfs, gfs2, hostfs, jfs, minix, > nilfs2, ntfs, ocfs2, reiserfs, sysv, ubifs, udf, ufs, vboxsf) is to give > them a writepages, and ->migrate_folio if missing, yes. > modelled on iomap_writepages(). Seems that adding > a block_writepages() might be a useful thing for me to do? We have mpage_writepages which basically is the ->writepages counterpart to block_write_full_page. The only caveat is of course that it can use multi-block mappings from the get_bock callback, so we need to make sure the file systems don't do anything stupid there.