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 8742EC7EE33 for ; Wed, 1 Mar 2023 17:08:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A89556B0071; Wed, 1 Mar 2023 12:08:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A399C6B0072; Wed, 1 Mar 2023 12:08:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 90D326B0075; Wed, 1 Mar 2023 12:08:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 817B86B0071 for ; Wed, 1 Mar 2023 12:08:28 -0500 (EST) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 2F10F120D3B for ; Wed, 1 Mar 2023 17:08:28 +0000 (UTC) X-FDA: 80520963096.17.3A76EB1 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf20.hostedemail.com (Postfix) with ESMTP id 33CA41C0026 for ; Wed, 1 Mar 2023 17:08:25 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="V5r/1J8X"; spf=pass (imf20.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677690506; 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=gSqGCCkBRHAi+X0hbDYCp2Hbzr+ulogfA++kvGN9a5k=; b=T/dt4qIvoyFhzaaFAmUEdarkPTnRbNeIsBrzULTvmyO5C0NMtiqRUTWURC2QfKAjV9j9oG Tmt0GhYokP7dFBjZGXJcqoZVDBSZuLSpGb73Ul39RChOqiW/1C/jrI+oy2bLhrP2FUaPKy qK7EOV+KhsTZboG06WZJMZ122xqDQ+s= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b="V5r/1J8X"; spf=pass (imf20.hostedemail.com: domain of djwong@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=djwong@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677690506; a=rsa-sha256; cv=none; b=xgzyMdrUKe5lzB7IjCHRVnruLIsWVvb7lVbr27KFIwtr5umoCwVMaJNozUCRj+fs+E7cyS JpHhPWzYR6xg8C9dinPEOzf1fdhRSLWBMF12y6yy9hdzREhngfWyZRkXgxJ+RTDhjTJKCZ /S3OjAjBlWAyPM7TA0gpPRosTRq3xAQ= Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2F57D6124D; Wed, 1 Mar 2023 17:08:25 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 86060C433D2; Wed, 1 Mar 2023 17:08:24 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1677690504; bh=20lsOtTm3VJqpNG3SKHu4vMMMyKHulIUG/bHI55Os4s=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=V5r/1J8Xe9cZzoqSPWjbfbKOqkRDCHtzjModu0bIIgoW6l4y0Qm4/I4dG5vSxZy14 FocsRvLqt48DOnLr4eD8fXogzp1NcAE0PfyIUA3qbpBXV30yp+jjj28syRfTesW6wk r0fSkgzlE3oOYlFixNO5eNSmR4y0UPsw+C+9EsK03UkfSXrcKHMTZAYuNFZ406LfaY 295CGP3m8iMHMaw4F4kNjNNusobdfJgfqhXapsbjgAJ3NCtJlhG+AxxMR3miD8nmcG AwSxElXJQLKTly59PBXTHbdujUPmjivceaZ3AwS8v07CdwT0AIAnEA0YySYCamxW9k MBNUbcJeToC0g== Date: Wed, 1 Mar 2023 09:08:23 -0800 From: "Darrick J. Wong" To: Ritesh Harjani Cc: Luis Chamberlain , lsf-pc@lists.linux-foundation.org, Christoph Hellwig , Matthew Wilcox , David Howells , "kbus >> 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> <87wn40mmpf.fsf@doe.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87wn40mmpf.fsf@doe.com> X-Rspam-User: X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 33CA41C0026 X-Stat-Signature: p7uwtofqtz78ippj5ry651gceqrhzm9a X-HE-Tag: 1677690505-20481 X-HE-Meta: U2FsdGVkX1+nF5fUxrYdFDV10OlMen4QHnFurLAZajMgR5TkMvbgRutw1mkSvC7rDYp/t7SWkhCtGrMZYX0nT8JkAyM68/S8WQePD83gfxDbjEjXr29ccuijlqnDSo/4GMCI0USNamtLzqPEq1ko1XShUim0Wshdw9JC3qSyGXkS/mBfRcdu2O06Ql7Lmx1wG82hPxda3xqlm6/YZwm5mlYEQw3tSMqGzhgzNTRSvOFFJU4FbJvlpnBU23m8q8A2HWCV2sTOLVXCgMis00XyxAQ4rGz3lYApCaRYjiAP0ji0ME5aLF9g66xFQ/xeuwj4DKACqEq/hUHuiObPqaN+FtQCZSwc7/nhqBhpBzpU3dPCWepk2qSwKn0xjfy6IG+qwTVcb+5wyD0rS6GwEz+Ag3nYFteZixpkPe6G/UrbkAu8flHaKxKG6M4yEKIvFuC8GsNyRiI5VdwMXvFT67ifmmZfcwVb9O7aFnpOqGbr8YXRWMEDulSM7oC/ERsp1lA79OAPmFbqU4hpSOaDiZVh1rsarJ5sBofIJOSg/3UBcKR6Nem22G6ZkbmEfM8c7TWmS2xI3ZEGjsU4Q3EWuNdLSqG4VXqQBOK6dWaDVHGLClqlp3NeR4DOLY99RXYJzFGKtJuPjencCMtbHwBeruIE/gB5FN1XqduW4xblKi7l4TNoMvs9ZgijV6XFgMlwulNgoc+0yQhjTN/4TUt1SJgqetK45jZMQCtTefl7QwrNM6FrT1k35ES9CD18ksr8Xr03FOQmYCKx+S33E9NikWFCbOmD2zBof4g8CwRgRfPmNZf9dfkW2XR1ocJvztBYAkcGqcOSA/iehbhv0458eTXNTQOc8uM8yUBrUwUmVDyWdY43hGXo9oNXXpa4eCVVhQcsyvR1xvjJxapP8Mw0DejMgaCvBYucYsIETSa0K876ryu2eHVSu9kKC7DsEbnnojPHwAaeO4bRaRuMqX6WhUd X/fvWtME baHxxGtDcS8LFNMOXj3gDyY6073j0pSeRcbHclnAMq0d7oemE//tmBo+nmO9Dpr4m0NN5KSb2IT2iLh4VCSiNW4mftBTCGvo16mhMeFB5ihHSouk3W7SXWLdqejmCjxo35bzxWlqnYgMpVrcdrkixh9TmBkiWgwlwd7dZ1dtk6z0b8Izd52YKNBaF0sToor+LpbJIlXPEta4gYidiNF7VcrZluCoHFKZPf5X/b1xlvtCLhC5vrCzRNmMfB7wWAiNdxACs3s7Ag/yV3HMpzDJPlfiRcTjdnp2jUFAI6g0KOKi02LxveUH++f/zdVs9mIcdLxRHxT7bP6pxRGGIeIyRLcmm80qJi5Vtg9xPf+13mQ/gNje2nJ7TeSj73+Swls4kt3EAVuC9vviHDkj9tR+Y4INKQ5qcGwOp3m0rosL+pI28H/kyg2H2HYp+Bw== 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, Mar 01, 2023 at 10:29:56PM +0530, Ritesh Harjani wrote: > Luis Chamberlain writes: > > > One of the recurring themes that comes up at LSF is "iomap has little > > to no documentation, it is hard to use". I've only recently taken a > > little nose dive into it, and so I also can frankly admit to say I don't > > grok it well either yet. However, the *general* motivation and value is clear: > > avoiding the old ugly monster of struct buffer_head, and abstracting > > the page cache for non network filesystems, and that is because for > > network filesystems my understanding is that we have another side effort > > for that. We could go a bit down memory lane on prior attempts to kill > > the struct buffer_head evil demon from Linux, or why its evil, but I'm not > > sure if recapping that is useful at this point in time, let me know, I could > > do that if it helps if folks want to talk about this at LSF. For now I rather > > It would certainly help to hear on what are our plans of > IOMAP_F_BUFFER_HEAD flag and it's related code. I know it is there > for gfs2, but it would be good to know on what are our plans before we > start converting all other filesystems to move to iomap? > Do we advise on not to use this path for other filesystems? Do we plan > to deprecate it in order to kill buffer heads in future? > e.g. > root> git grep "buffer_head" fs/iomap/ > fs/iomap/buffered-io.c:#include > > Wanted more insights on this and our plans w.r.t other filesystem > wanting to use it. So a short walk down the memory lane and our plans > for future w.r.t IOMAP_F_BUFFER_HEAD would certainly help. For filesystems considering an iomap port, my advice is: If your filesystem is simple (e.g. direct overwrites, no cow, no verity, no fscrypt, etc) then you ought to consider jumping to iomap directly and moving off bufferheads forever. If I were working on a port of something simple(ish) like ext2 or fat or something, that's how I'd go. Obviously, any filesystem that does not use bufferheads and ports to iomap should go straight there. Do not *start* using bufferheads. For filesystems where things are more complicated (ext4/jbd2) it might make more sense to port to iomap with bufferheads in one release to make sure you've gotten the locking, iomap-ops, and writeback working correctly. Once that's done, then move off bufferheads. gfs2 might want to move off of bufferheads some day, but I think they're still letting the dust settle on the new iomap plumbing. IOWs, I don't see IOMAP_F_BUFFER_HEAD going away until there's no longer any interest in it. --D > Thanks > -ritesh