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 ACAAFC64ED8 for ; Mon, 27 Feb 2023 21:02:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0AAB46B0071; Mon, 27 Feb 2023 16:02:49 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 05A946B0072; Mon, 27 Feb 2023 16:02:48 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E64CE6B0074; Mon, 27 Feb 2023 16:02:48 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id D68456B0071 for ; Mon, 27 Feb 2023 16:02:48 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 570DFAB030 for ; Mon, 27 Feb 2023 21:02:48 +0000 (UTC) X-FDA: 80514296016.11.9E34D47 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf13.hostedemail.com (Postfix) with ESMTP id 0E5CF20016 for ; Mon, 27 Feb 2023 21:02:44 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=OcT3ucNu; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677531766; a=rsa-sha256; cv=none; b=mGyVjfBLwGgURub5gTUKyw4z3szBM3pPmyiFYdexZveT/fZsDRMI6nPFGWOu6gN0WYkuUl wzW5PhR+coCL80ip338YwbOQ4dHSs9kDQ0wyBgGLuRLgSjxRDCAJH5+H2apGA9EHKyAMHq EPv6KiTuyZSQyn7gvgGWqECIjERhFUE= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=OcT3ucNu; spf=none (imf13.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677531766; 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:dkim-signature; bh=tob57UFyeBCiGpzZYnSrMZZK1HMTjtbuXQGmlUbhJd4=; b=zS06b346jQ5w7h3NorIf9es6uqD4KashEGzIikSDGUaVLdOU7LR27K/M3MOFZCoWQ9Nnt+ VHPDYnXW+FKPdFuC/UXHvse5y0ttak+U0ZKE6G12qSdha1VUH1dy3XwfSX1PD7m3Sm4kFD E1Vnb/0uRt7IFHZi+z+5VwdpDFoZrRo= 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=tob57UFyeBCiGpzZYnSrMZZK1HMTjtbuXQGmlUbhJd4=; b=OcT3ucNukKyKdSx3bbfTRw37ku r9l0Sj2A1kT+BQmFitLRNFixcUmkpbVZ2KI9UY6B0QUle773f03ihOmgdwuG9cdqkk979mjShGyHf xmSya6JPzQ9u0uY833JmPAJ3UeEAjM4SzjPqv/AQl39kRY/HftifHNPX3ZQKlT+yxqMKhyZs2gADk eLzMpW9KFAuwGdE4TPpy1BLhS8aKiUhgJOVsj040OAwBP/d94nQrfp0WUoE3Ur1NMM2di81P0UB5I tTio6GKDZX3F9e6ARZiY0oT3uA6tMpm/L7ueoh5vjGwHyjkEILw5A20KBsrg2H519UHHB3oO1SLv0 v3tIkI+A==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pWkdh-000Oid-NR; Mon, 27 Feb 2023 21:02:29 +0000 Date: Mon, 27 Feb 2023 21:02:29 +0000 From: Matthew Wilcox To: "Darrick J. Wong" Cc: Jan Kara , Luis Chamberlain , lsf-pc@lists.linux-foundation.org, Christoph Hellwig , David Howells , "kbus @imap.suse.de>> Keith Busch" , Pankaj Raghav , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: Re: LSF/MM/BPF 2023 IOMAP conversion status update Message-ID: References: <20230129044645.3cb2ayyxwxvxzhah@garbanzo> <20230208160422.m4d4rx6kg57xm5xk@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 0E5CF20016 X-Rspamd-Server: rspam01 X-Stat-Signature: g5xpsziietxz8wwz7xpanyjo1bhgffht X-HE-Tag: 1677531764-60198 X-HE-Meta: U2FsdGVkX18k7m2MIRzJz0uSaCjci24aGFPzw5g0p+OXhUAFJ3VYXlPej6MyEe5aew/M3d7V6hbj6X9s6iZ3aePqHmt0eiJUvpzsRV0DuvgKL85FK9YQXVEbef3d4H9fUAvlft53845lgjRh/IbdUEj9BwBMUXxL+CpnK4bZlaGBtzP2y/YyxG861JPqXbwXTqfPh8J98aHCanhaFDMZnldd8PGNuK7Hy39bSUthfepb54aQAXb+2NfyokOcKjCPslvMkVHABNqQ7VVY7X4lCBU2lHl29f+xw9rRxSrbxJlqbC/9sI0zwn2ZVKUtWkZ+UEe7sjiZhdFJouSayODkYdpRV4DJzagbfip93qOPTUld7xeLA6+ywMK8UP/URRQ5kfblzPAhEN/K/8HA2pDyJGohEOMTOaimZUCKdi0LzgNhVtY+Z97WOdI0s3bDzpIDWnsOaVUySVrua8urVbGwSZhWy1pgUZpFSXh+GioDBdQr/EClaRvoLPw3Y7wPUvFXKDXlXTdpkIUOo9jMPtUlpqrnWrea7mW2HdKOdk0AgmHBzp9mHuDAGxS5NrZzN/fZV004+WIryaGHvQeuqesBv6WCmd0OECXzJkT6KZ5HPuHOynv59UO+vHNEQaPB0MvkqSPMkQJLR56DncVejj10vqTUIAj4O1hwKO6rQMKFB/MRUHIOaW8tuh3Ml+84SvyiORFbaGGTj1T5p0tPDOI2Oi/16ppX0Xai9tFdSTial/H4RGvamflfX+nemc8LxeR7PzWhzazgls4wf2SYqpK7cwmULtWVidtrE/TqEkk+/oj4Wn74RtmglyIu1jAj5rH4OBbNLhfHAK81jnbRD3VtjxgpRhL9kaEwDhIg2JI/ss2GlvDG0xZyW8yp8k4YU3qM76ZCF/+mU9IOxXeVaES53VPZG+GwuvT7+CXRoleXrazfCnc+oavqPz3+II0tbKq7Dqd8/jYo8mkc/J9lV1r YjiI//XO 5qWx1qNAjDQ1oYQAhvsycWd2bFjUwJb99wlHaLLJ3LM6jfsIKDukDy6zcdnBU7q4OTk87ub3ViwsH1QnXvk86GYu0oVZVW0iTW+p4i89b7TKE/mQsSgNxz6f7Qc0IIPF4TdP7DZwKLIucRd4EOkwKMl+egccYxgnQEuWKfLW1nsp4Wr3fky+JJiIPxzjJW/7aEv2I26239q03cPYEbaWmldwRcHn0efDEslYO+00X+HEhtjU= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000875, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Feb 27, 2023 at 11:26:17AM -0800, Darrick J. Wong wrote: > > As I wrote above, for metadata there ought to be something as otherwise it > > will be real pain (and no gain really). But I guess the concrete API only > > matterializes once we attempt a conversion of some filesystem like ext2. > > I'll try to have a look into that, at least the obvious preparatory steps > > like converting the data paths to iomap. > > willy's tried this. Well, I started on it. The first thing I looked at was trying to decide how to handle the equivalent of BH_boundary: https://lore.kernel.org/linux-fsdevel/20200320144014.3276-1-willy@infradead.org/ I'm no longer sure that's the right approach. Maybe we do want to have an IOMAP_F_BOUNDARY to indicate that the bio should be submitted before calling iomap_iter() again. But we're definitely still missing the piece where we start the I/O to the page by setting iop->read_bytes_pending to folio_size() and then subtract off each piece as we either zero it or the I/O completes. I have a bunch of other pagecache / fs work queued up for this cycle, so I wasn't planning on leaping back into this. But it's worth making sure hat people know about one of the problems we figured out three years ago: https://lore.kernel.org/linux-fsdevel/20200505190825.GB5694@magnolia/