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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 79E49C61DA4 for ; Thu, 9 Mar 2023 20:52:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230060AbjCIUwM (ORCPT ); Thu, 9 Mar 2023 15:52:12 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37716 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231401AbjCIUv4 (ORCPT ); Thu, 9 Mar 2023 15:51:56 -0500 Received: from bedivere.hansenpartnership.com (bedivere.hansenpartnership.com [IPv6:2607:fcd0:100:8a00::2]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AC91010461D; Thu, 9 Mar 2023 12:50:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1678394995; bh=TxNC+G8LJt1YlLEyyO36tP7EdfEi7ZRgBLptFhwSu+0=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=sJEOIS4cFgIO/Gb3uL4riI/afgPmTw0aGi1iYex2KToml7qBwNYZz5e56YLxQQUXv 0yXD+I+GxID+a/Djk4E3O4x62qWnbI7um0UgUr2mkqnN1ut2zMBuJNdCjW75akIEYf /xVnm8xggxb7KxUbSMTNO3BukSpUPqDaJNbqB5P0= Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 5B1B81285F61; Thu, 9 Mar 2023 15:49:55 -0500 (EST) Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5svhtc5N2jGL; Thu, 9 Mar 2023 15:49:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hansenpartnership.com; s=20151216; t=1678394993; bh=TxNC+G8LJt1YlLEyyO36tP7EdfEi7ZRgBLptFhwSu+0=; h=Message-ID:Subject:From:To:Date:In-Reply-To:References:From; b=adb3KIoqy9AY/YQj6fgspkWFfMJOJnXe2iyCMOb8KkL5/RtLXMg4VOOA6OVffTayu 65wN04qMjXIBC8yi9Bpr9sToDrJTWW0Gju2Uy/Gws8YVkoGquUTf4D5SAxTi5dP9fw TlgQQ1iXlSF58IkiouMxOPBOIh0l9W9QqpYd5NlQ= Received: from lingrow.int.hansenpartnership.com (unknown [IPv6:2601:5c4:4302:c21::c14]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id ACB4F1285ECE; Thu, 9 Mar 2023 15:49:52 -0500 (EST) Message-ID: Subject: Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations From: James Bottomley To: "Martin K. Petersen" Cc: Javier =?ISO-8859-1?Q?Gonz=E1lez?= , Matthew Wilcox , Theodore Ts'o , Hannes Reinecke , Luis Chamberlain , Keith Busch , Pankaj Raghav , Daniel Gomez , lsf-pc@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-block@vger.kernel.org Date: Thu, 09 Mar 2023 15:49:50 -0500 In-Reply-To: References: <0b70deae-9fc7-ca33-5737-85d7532b3d33@suse.de> <20230306161214.GB959362@mit.edu> <1367983d4fa09dcb63e29db2e8be3030ae6f6e8c.camel@HansenPartnership.com> <20230309080434.tnr33rhzh3a5yc5q@ArmHalley.local> <260064c68b61f4a7bc49f09499e1c107e2a28f31.camel@HansenPartnership.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.42.4 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Thu, 2023-03-09 at 10:23 -0500, Martin K. Petersen wrote: > > This is not to say I think larger block sizes is in any way a bad > > idea ... I just think that given the history, it will be driven by > > application needs rather than what the manufacturers tell us. > > I think it would be beneficial for Linux to support filesystem blocks > larger than the page size. Based on experience outlined above, I am > not convinced larger logical block sizes will get much traction. But > that doesn't prevent devices from advertising larger > physical/minimum/optimal I/O sizes and for us to handle those more > gracefully than we currently do. Right, I was wondering if we could try to persuade the Manufacturers to advertise a more meaningful optimal I/O size ... But as you say, the pressure is coming from applications and filesystems for larger block sizes and that will create I/O patterns that are more beneficial to the underlying device hardware regardless of whether it actually tells us anything about what it would like. James