From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Date: Thu, 11 Aug 2022 07:58:11 +0200 Subject: [Cluster-devel] remove iomap_writepage v2 In-Reply-To: References: <20220719041311.709250-1-hch@lst.de> <20220728111016.uwbaywprzkzne7ib@quack3> <20220729092216.GE3493@suse.de> <20220729141145.GA31605@lst.de> Message-ID: <20220811055811.GA12359@lst.de> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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.