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 416A9C61D97 for ; Sun, 29 Jan 2023 04:46:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 38FD46B0072; Sat, 28 Jan 2023 23:46:52 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FB426B0073; Sat, 28 Jan 2023 23:46:52 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 192E06B0074; Sat, 28 Jan 2023 23:46:52 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 010F16B0072 for ; Sat, 28 Jan 2023 23:46:51 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id C082BA0152 for ; Sun, 29 Jan 2023 04:46:51 +0000 (UTC) X-FDA: 80406601422.25.2CA139A Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by imf13.hostedemail.com (Postfix) with ESMTP id 0850620006 for ; Sun, 29 Jan 2023 04:46:49 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ufQj8BLs; spf=pass (imf13.hostedemail.com: domain of mcgrof@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=mcgrof@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=1674967610; 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: references:dkim-signature; bh=ZbUYpnmWrhOptfDOcPYCJS615i2dTcIaktaE37VBkEY=; b=s0o3IVA/qW5aNr98cErk6c0nShaDwHG7GCFt9RpffLO56h4M7G1Y40pauT8qNth6HICFUX WXIGkphlV3lBKTFuemuel1C53+Tz//ocCuiNpG/W1c195PFS2tPi6puB2EZ9ZrtundiJpA GMV3FN7RdiFBxDuI4TRRhlLSbddWUQU= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ufQj8BLs; spf=pass (imf13.hostedemail.com: domain of mcgrof@kernel.org designates 145.40.68.75 as permitted sender) smtp.mailfrom=mcgrof@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1674967610; a=rsa-sha256; cv=none; b=6cA8vvvVnn/VCEsjwXF3VmyHD4IwgMP/e0N1xmzG+htMEjdWNX2k6Y+dniznqG6FcfvCks +D8/npeUIqOvniX/nTiPRILJQTr3Jstmgw2Drff+wY1HvbUvE/neDMGlL72FY7Rhz5kFVH n/XEThe5MB6p54NRi00t9SZ+pJn9Rrw= 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 ams.source.kernel.org (Postfix) with ESMTPS id 623AFB80966; Sun, 29 Jan 2023 04:46:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B6D9AC433EF; Sun, 29 Jan 2023 04:46:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1674967607; bh=PXwJncBGl8HG9How7WEgeo2qflyTk4vfxxh5fbr+634=; h=Date:From:To:Cc:Subject:From; b=ufQj8BLsDz7vPIW0y4QhPF1lNXOCZbkK3dUzpumg37HbMIlRyNvF5BB9EaX5XxEBU a6PmZJ0YLe4yTDd4W+vPKqzdUzYvesFvmmeMEivgFSN7vDtlY5BlyNctl2jJrMbeOI tHPf8wUYzkEAfRrIDg5ztscwkS9x3SoY8HMXu5CxWj1vm7ZJsNPvPbYrTUCO6pVqPI 0cAuI+YeZfB+WJ34QWXsU6cnLRv68wnfwBROS8OHoQrxIrXJ9usDKGtjyxtRBM3Pbw hreREhVNBWFyTzQDp3l2jC459ExvXD8VIye9B6BFRWY2WccPpo0j7TnmA4CHTFKmN9 /GfWWjstYfo3g== Date: Sat, 28 Jan 2023 20:46:45 -0800 From: Luis Chamberlain To: lsf-pc@lists.linux-foundation.org, Christoph Hellwig , Matthew Wilcox , David Howells Cc: Luis Chamberlain , "kbus >> Keith Busch" , Pankaj Raghav , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org Subject: LSF/MM/BPF 2023 IOMAP conversion status update Message-ID: <20230129044645.3cb2ayyxwxvxzhah@garbanzo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: jnu764aocfti4k77nfojp5srdkn3d1tb X-Rspamd-Queue-Id: 0850620006 X-HE-Tag: 1674967609-194465 X-HE-Meta: U2FsdGVkX18Hk/ijFRl3SGHAqXBqvszmEy8rP5OicV1NYmpQTleyWqwptKBzradK0i8IVFJRT3H1s0LxehSgOe93sYwn28CkRk19U+hbcgVNGLF5RyqjZd2N6E5XIq/JLZd3ipyzsv73NnmqOtpQyXwA3bu181mpzBPxGsMjcd3sm4it432x0tIbdCQV1tgWsZTtcDn14VWof97reYTVuHQyHGVTjnxQQrtW1Ynz3uXALhmtB8OFtltHpJaTqu6hJtP32VojSvbxcI/fhcofc7h5oZ0TKcrkq8wMNrbXJtmsIwQ2bWzvi7VzZHG0gz5gpVdbDSFHBGEsQDtJg/7WmnaC58I20YCcg4fAWAENuaSGdd88MmxTL1NpKhSvmuwj4Q0+bsbuvt0Adrn7OGrVe7vpQM0vLGg+CunWaEgLPWu/32BcNpqcWAJd+R1pd1cZHua1lTM1Sglo4zwOVjaJJR4ss8P/pcIoicOdZN+EVYiCwTqgF+Nqsla/bF7yn2U/r7mj0Kx7pRuNM/eWjX1xRLrZ5RDQw7hYrcgjZ43jWUrInRRxpdMzfkMu6ZXLDoCuBkepFK5Qeu4UK7KOKx0Zd5UYnLxd24IENvQUr79qxXap8d1POxNWj2rEFI6x9TKpJ3JGQ4ZshFJKiK1/W1H4CuxXrn9cnjDrOH3W9FNLRaTpAYq+g8VDAV7rt6R3/jLvzKHiAirU90uxnHZQ9WtoEnl9tTOD1xyB4f2MwCpRmQztQxuiRs/UIJcSzBRgiG2ztreImVjyjoDm6PNWsimeihVxsL5QrZY5jEoYIqh5KHenhEwaGSyx75MmWqetkzeZGJ8gzJJmhRWkn0Su+3KN/Vdp/+ShKVQoUm07L89pqit3OGpziw+JTbGho60RJ+BYEtVvK0VA8parAG3quo+CoYEZbZa82flqpBt+TEo82TJsY1/MotEDAIVNBUiJEi49Zk3Et/PePtwbNjyeUHG PdCjOmdh yJI7BwXuuqQ9fFZxaRtOIdfPyOpzXu4nYLTXlpPg+Adui4ygmJNWTz7HnYklLWi86Fhh1aXrCWyXlzcp4wpFPeq9b77ye4TsWkhIvgGlvJx3p61aandW+DTNCw8LBzOmAlbkCBLz9fiweX1z3oPGbCkePEFMi9oh2Fz9aRlCavDsUZG+eEYHdqiTuUmNxAOsSIGgAQ+KQv58+9fuePalHlxZQhcxtHl2nlF2GNEaxDEvRRaEbTeS30un/cTsRCEUHwbsbzA76F6lVE5qatL7J6jGMoUZllae0lKYeFKXlK21k01YlwSWRUYmRw/MtErXexSEUzwvMeHy8Hqc= 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: 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 instead focus on sharing efforts to review where we are today on the effort towards conversion towards IOMAP for some of the major filesystems: https://docs.google.com/presentation/d/e/2PACX-1vSN4TmhiTu1c6HNv6_gJZFqbFZpbF7GkABllSwJw5iLnSYKkkO-etQJ3AySYEbgJA/pub?start=true&loop=false&delayms=3000&slide=id.g189cfd05063_0_225 I'm hoping this *might* be useful to some, but I fear it may leave quite a bit of folks with more questions than answers as it did for me. And hence I figured that *this aspect of this topic* perhaps might be a good topic for LSF. The end goal would hopefully then be finally enabling us to document IOMAP API properly and helping with the whole conversion effort. My gatherings from this quick review of API evolution and use is that, XFS is *certainly* a first class citizen user. No surprise there if a lot of the effort came out from XFS. And even though btrfs now avoids the evil struct buffer_head monster, its use of the IOMAP API seems *dramatically* different than XFS, and it probably puzzles many. Is it that btrfs managed to just get rid of struct buffer_head use but missed fully abstracting working with the page cache? How does one check? What semantics do we look for? When looking to see if one can help on the conversion front with other filesystems it begs the question what is the correct real end goal. What should one strive for? And it also gets me wondering, if we wanted to abstract the page cache from scratch again, would we have done this a bit differently now? Are there lessons from the network filesystem side of things which can be shared? If so it gets me wondering if this instead should be about why that's a good idea and what should that look like. Perhaps fs/buffers.c could be converted to folios only, and be done with it. But would we be loosing out on something? What would that be? Luis