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 23F6AC48BF6 for ; Thu, 7 Mar 2024 07:29:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7CDF76B0114; Thu, 7 Mar 2024 02:29:44 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 75C346B0115; Thu, 7 Mar 2024 02:29:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 61DAE6B0116; Thu, 7 Mar 2024 02:29:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 3766C6B0114 for ; Thu, 7 Mar 2024 02:29:44 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id A32DE1210D9 for ; Thu, 7 Mar 2024 07:29:43 +0000 (UTC) X-FDA: 81869418246.03.CE1A31C Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf13.hostedemail.com (Postfix) with ESMTP id E340E2001E for ; Thu, 7 Mar 2024 07:29:40 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=LrwkogI5; spf=none (imf13.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1709796582; h=from:from:sender: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=5zuLqYXEcrU0IPXnJfRZey6qQ6C1CibUgZYtXv3ee+4=; b=QIGlNuA5cmNd39bzUMcZLm715V9dVRFil0+fXaA6z/5ZcFktOWdWVpkNPCL+xd+P8zHUOs +hTfCZxPjQzZSnvMdoDOocXlQYumMp+OqC7zFcOcvlcXtWOuIgFHJUQOG2Dj2nSh3W3nQs odoqjPPHO+NueeA5Lp334WygkUOnd84= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1709796582; a=rsa-sha256; cv=none; b=e62YuEE6oxdKIx7YCiUlEzep/z/iCh9MfzSlHSI9Z8pH4GabphloXXaUYsibD3YMlwjjod gx+uZSTI5SVIKf5Y37oiBbrEs1xwia52Pdo8OFIFw94utuHpYo9gbVlFyssAIbedBLC+1T clmZUGeNOWnvs5BkPoPGU/sB8MXegWc= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=LrwkogI5; spf=none (imf13.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=Sender:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=5zuLqYXEcrU0IPXnJfRZey6qQ6C1CibUgZYtXv3ee+4=; b=LrwkogI5MD3mB2ZKZDtdSnB8XN USTKsHnJIQsl120q7UgahKq6PX8viZIMVtqHYuNF8bchMfZ6noelYGfxyaF0v28nZ+jAzb/xIT0+x dgmtwMvJAUODmYfh2JFjSV5gS5t7YjhElxBlSiCN+bnD+qwnYk4/tOiOExfXiSoBqi17Jcs2dB2J/ zN4CmjI1VG2oUjCHv1mMiI931lkUGOWImvsLvWZCNdmj7+bP+yyy+W0Z0Y+01jBie28NU1vIKFWtu wq4J1/aqGdnn5KtJJvkduVCBctmBuHIM8HRURw1EOMsCilW2MR46oF6bs5SGCXYdwbmjAy8mCyB1h rAXeLLTw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1ri8C6-00000003Qme-3F6u; Thu, 07 Mar 2024 07:29:34 +0000 Date: Wed, 6 Mar 2024 23:29:34 -0800 From: Luis Chamberlain To: Dave Chinner Cc: "kbus @pop.gmail.com>> Keith Busch" , NeilBrown , Tso Ted , Matthew Wilcox , Daniel Gomez , Pankaj Raghav , Jan Kara , Bart Van Assche , Christoph Hellwig , Hannes Reinecke , Javier =?iso-8859-1?Q?Gonz=E1lez?= , lsf-pc@lists.linuxfoundation.org, linux-mm@kvack.org, linux-block@vger.kernel.org, linux-scsi@vger.kernel.org, "linux-nvme@lists.infradead.org" Subject: Re: [LSF/MM/BPF TOPIC] Large block for I/O Message-ID: References: <5c356222-fe9e-41b0-b7fe-218fbcde4573@acm.org> <9b46c48f-d7c4-4ed3-a644-fba90850eab8@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: E340E2001E X-Rspam-User: X-Stat-Signature: 46apbybiqtisddqkw8m698ss9po39nak X-Rspamd-Server: rspam03 X-HE-Tag: 1709796580-575712 X-HE-Meta: U2FsdGVkX1+WkVniOiWJ1ajqg7KgxJJNOqbaxjHPGU7uMe/CrYiJzTfU/qiXNnkxLOAddLfHEaZFFKVW4OKC5OYV0fuitb++Qefut1QXfywlspOJ6yCrg8G9ns7kLMyZy181CkMN+Ut5zXLVjA+0zjyfDmnbeLkMDPTsmY0MTXcMT5zGeQ9JaE6Nk9phbCbgu+5d2v3UtHsQ77ZdrRCzhUckeqNbddEvg1tMn7w3zkd1XrwHF3n52lIOjCXJobZY5XWuoSaFqjeKqqYO2b+Boe7HlGSt6wlfcOE12W4IujwVNlwBbYB+cV41uD3APohNzV+gZNJDqobJ8hQFXp8ZLn/Eza8FeXpH15lkhtvah3f7g4yQk+OYjRPQWP5MzDkRwIa/NpdMNkt88iA9mle2Yp+GhP7MdOfBftTGCvj6iiwLKj+fhtmjbnTkhMzOzuvPgvB+uFSox2vM/0UOZnFnMYCZqSysDdgYtB7mk2NDnEL2n+seNph75YkrouFbuZ/8guI8LehB3t/klyQnuik2+8mTH9H1bBkEZX1t4b13eOZXYcjstQYCdiBYoag/IZIakBQ0dnsdG3LX9C4JfbDhIVTEab0UvSUs/PhzeUSGMdHiKF2myBipeJPZu06WHNOdyDqHQyONdbhNeN8E7iRUdEo6+cCUH9rT+2O/B3XzTl57PpMtb9wS7WojL6PybaMRAHWekGH5eMJ7HnhB/e6dKWQE8Cx0KPdXLZeVh9v6C4jSs5XLdzMOxR8wCTbv+vAVu802wlB+RfBmKwthUCdK09ZAcwq18ay/OSRfZJ/CteaX/kYvyfgpFNeUEdAEPDaeFgaZ4DzUkJyO5IHaiXafYVqKJ2HL/ViimxpyIaR9QJIAbYDsas5Q0QzsCc+S6ylZca7+oFh7C8zm73S1ZElNMPjRqtTpDX8soSwsoL9Aiq5E2JDpi8VNk4eXQPTZFtnx28ZIgJhrJBRxKtZrP2X olFmwV+6 FVj/UzLxkEoOd8NGPGT1ilt2h3gGGYyv88QLLBsXAdDNzvik1Lq8CwSFR03ZlFpJwGbLc/zO7nZPUg3A= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Then it does seem we have everything we need already, and no changes are needed. Because these drives *do* support the logical block size advertised, it's just not optimal. On Thu, Mar 07, 2024 at 04:31:48PM +1100, Dave Chinner wrote: > Sure, doing 512 byte aligned/sized IO to a 4kB sector sizer device > is not optimal. IO will to the file will be completely serialised > because they are sub-fs-block DIO writes, but it does work because > the underlying device allows it. Nobody wanting a performant > application will want to do this, It's a good time to ask though if there may be users who want to opt-in to promote this sort of situation so that the logical block size is lifted to prevent any IOs. For NVMe drives it could be where the atomic >= Indirection Unit (IU). This is applicable even today on a 4k IU drive with 4k atomic support. Who would want this? Since any IO issued to a drive which is smaller than the IU implicates a RMW, it means your if you restrict the drive to only IOs matching the IU could in theory improve endurance. > but there are cases where this case fulfils important functional requirements. Sure. > e.g. fs tools and loop devices that use direct IO to access file > based filesystem images that have 512 byte sector size will just > work on such a fs and storage setup, even though the host filesystem > isn't configured to use 512 byte sector alignment directly > itself.... It would seem like quite a bit of things. This is useful, thanks. Luis