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 19ABCC46CD2 for ; Fri, 22 Dec 2023 05:13:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 92FD86B007D; Fri, 22 Dec 2023 00:13:53 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 8E0386B0080; Fri, 22 Dec 2023 00:13:53 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 7CEC36B0081; Fri, 22 Dec 2023 00:13:53 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 6D65D6B007D for ; Fri, 22 Dec 2023 00:13:53 -0500 (EST) Received: from smtpin13.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 4A0F140784 for ; Fri, 22 Dec 2023 05:13:53 +0000 (UTC) X-FDA: 81593287146.13.F077270 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf24.hostedemail.com (Postfix) with ESMTP id 3A3C9180003 for ; Fri, 22 Dec 2023 05:13:50 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FJLHiuOd; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703222031; 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=3shKBIvhLWjsCiSjY85TEmaxzTG7BMW14R+xGNs9tzU=; b=nJLFyHa2OW3s6DiHC/Z+YfWD1TJVJ24oiB0hdVfOOjr9Lvk4Xdvwx4MMAlklmXnL86vLvS edfyG5Xequ+tzAH2Wz5qz4H0hqp1MqLGQPIW2SGRAIJBioZEyWm0OPy2k2GlRHJuxeQczL t6V+mfTQixPmY/XGXiMYyHUldjzNNbY= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=FJLHiuOd; dmarc=none; spf=none (imf24.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703222031; a=rsa-sha256; cv=none; b=ObYI1+vd7KBh+oo4/orwYyUvNZNwxOBlQfzsNSmRW+qN1VImOeGy3I7qPWx3r4fuppGowb 28aJnU+73iuumqgsZuptay9ef5UZ+tOi4wzx5eyaJDb7FVicZE7Ls1vCaBxvpbcOZaPTqx 89NFwVTUnn6/2wbqFOnRlAxwkJXtQkM= 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=3shKBIvhLWjsCiSjY85TEmaxzTG7BMW14R+xGNs9tzU=; b=FJLHiuOd8g/VKYYccOIaQxdGOZ +2fuv1sq672PBRaBDJFiQ4jDPcXQawRxmtlcgIoSZivPkVN/d+Y2jCaL0VQ8l4EHJ7En0Ts5mJeIy K1Ey6aZexE84ec/5gTBJNZnAIZhArgxCdoUcH1PN1PkPduPdUT5DjEu2Mb4oFe9G/ya1wI1fyb/SH Slza91DDVfucNamH/zqB6RwD9U6YCgQ9o+nOer4YNxItcpBjFRbcPF0P1lR9sXQY3DZHeXMXBDnG0 gn/E3zZYaMd1M1z4Eeg0luXFDWlqsVI3A7Q8W4bo4tqf7o23+KRqXrt/EBxGDtyI8blwCaInQyHAB zL+mUu4A==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rGXqx-007AOG-3A; Fri, 22 Dec 2023 05:13:43 +0000 Date: Fri, 22 Dec 2023 05:13:43 +0000 From: Matthew Wilcox To: Bart Van Assche Cc: Hannes Reinecke , 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: <7970ad75-ca6a-34b9-43ea-c6f67fe6eae6@iogearbox.net> <4343d07b-b1b2-d43b-c201-a48e89145e5c@iogearbox.net> <03ebbc5f-2ff5-4f3c-8c5b-544413c55257@suse.de> <5c356222-fe9e-41b0-b7fe-218fbcde4573@acm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5c356222-fe9e-41b0-b7fe-218fbcde4573@acm.org> X-Rspamd-Queue-Id: 3A3C9180003 X-Rspam-User: X-Rspamd-Server: rspam05 X-Stat-Signature: ngng3pr7oe1zg1hnwrj4ok43mymmdnxe X-HE-Tag: 1703222030-511003 X-HE-Meta: U2FsdGVkX191tzLoSd0R7BIK0cdILLiL5qYnm6tqQN7h19Z/MSThb9AhicB0+QMxVpixxwaAtHKZhKuTy6O1GNvu4v4SfXbV6VaymAvUkQt6bpA0EC2VW3Evcxf+tq8gndO/ZHa7xAopqE+a6Ze21fumzuPoS8mQ9yTo+KXJCCKigNvZ/2XF+UBvb0CIgiKxnUq4/KYFYwplbmpXftGgEWf/TQTpJPB03gi/yeEvZdEvGyQsXl10r3Txna4by2FpFNy5YypjGPuDwHxBodg7E8ViPv0nqWvXm/VbmEIPn72Frbtme8tMG4AT8pCotMl1y3pOz7WvkASN9sW4z41fDMo/KgrOSFrXtXsJWX20kVO3uPTqi62OO0jju2VpKDM1N9fxmiJl6L8rX4/MLi6LHpT3rLDqMarccSHTY7nzzNwCj05N4HpiH/RMkoByrufAFcc1gNFLiAfC63ddnJJFs+ZIkQiZBSuklCIlc2rcyyRuOpm3MpidjVTxJMsaYgX6PxuReQsspTqjMM1KXUGAkg6D7nFh4arJEU0nkzynErg+CpoQhReUaZ1Q2o0uusjGFIqxXtybug7zee9sTjWfLaZucZqClHPt5u9KAlfpC9S9SEc+b1PTaTwK15PYNuzh+X36VTKNlg93CJUTkcUKwj2oJtiHp98E1fc2yyJxy8ut0nn5q1S24JjRaH8KhiVxBv4n7x9HCq7KpYkvlCy2hihbOJzD1mOVCecwDB4Qn8oRZ17UjSFv1lbsej1D+MymxAMuXmxiOw48Av+PHf66mqx7U704X84kJiH/NPsK7Af5NkfpAyvZbdctdWz1NbxcvdHK3iILBUojp2Z1z5oiSCceGGDZ+WJ+DPS/FTMzF+TqzYmSBYGZUfaTuy7+BiY1iO9hg5SceT3bJJGpZva8Vo7QssqKKBVQ5H4zv2MRGwo5zEDsxINTuIKOqaOPcDrKiNVSJhbVxF9CybAXr/s dnH3/O4D rdj5C3c9esrhoGRvDdlfsTIOt6tWw7Cwjt2tHVIUiusT9EzfrbsL+9dvuLg0wvW+lCB5YOtLy6T0tP+t/TFFsdDFUqLFeguQTV3g/tXE4ZKOF0VN2ca04XLsqYFcYzfr4ZJJuo7GcL4LuEjmeu3yPKRNjOJBiSsNEPOUsFHR/qwfwibU8zzftv83Glg== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000226, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Thu, Dec 21, 2023 at 12:33:08PM -0800, Bart Van Assche wrote: > I'm interested in this topic. But I'm wondering whether the disadvantages of > large blocks will be covered? Some NAND storage vendors are less than > enthusiast about increasing the logical block size beyond 4 KiB because it > increases the size of many writes to the device and hence increases write > amplification. I've been mulling this over for a few hours and I don't really understand it. The push for larger block sizes is coming from (some) storage vendors. If it doesn't make sense for (other) storage vendors, they don't have to do it. Just like nobody is forced to ship shingled drives, or vertical NAND or four-bit-per-cell or fill their drives with helium. Vendors do it if it makes sense for them, and don't if it doesn't. It clearly solves a problem (and the one I think it's solving is the size of the FTL map). But I can't see why we should stop working on it, just because not all drive manufacturers want to support it.