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 18058C61DA4 for ; Thu, 9 Mar 2023 21:14:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231137AbjCIVN6 (ORCPT ); Thu, 9 Mar 2023 16:13:58 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47266 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230511AbjCIVN5 (ORCPT ); Thu, 9 Mar 2023 16:13:57 -0500 Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2607:7c80:54:3::133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83575E776A; Thu, 9 Mar 2023 13:13:55 -0800 (PST) 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=GX/fcDjqXbiud8lYARujqcmOd9zxNY2CS9n0xDw/OGs=; b=O1xySUPqu8oelqWJnDI9b46D/h B0aUPXPLBAxzY19u8+ubwJQ9sAgSskDG072eZ7zz8msH2Oz+MICbvJeFfESJrk6VU9OXyiY2V6kiv /rlirrGGYmyzYfqZs2VTp1Y5sqDQF6LHGUSjQst9SfC0v3cm7MGZAgxNauc7TnYaGORyc3M80xjc7 P1/ibfUV0oYi/fLF28X78kwsMLolt0ieTIZ1Y6PlWuobkXVcvjbRfpEmhmYcdbdBXsLBLLWWuHIrM SVAZrLMnDUTiXe2AfYC4gV3ds68s3jLToVM4FEL5C4nmWL/OZWvhQbQhYJocr0xUp/YaGLpZFwYuL TSBhtuyw==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1paNa7-00BxAY-8M; Thu, 09 Mar 2023 21:13:47 +0000 Date: Thu, 9 Mar 2023 13:13:47 -0800 From: Luis Chamberlain To: James Bottomley , Dan Helmick Cc: "Martin K. Petersen" , Javier =?iso-8859-1?Q?Gonz=E1lez?= , Matthew Wilcox , Theodore Ts'o , Hannes Reinecke , 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 Subject: Re: [LSF/MM/BPF TOPIC] Cloud storage optimizations Message-ID: References: <0b70deae-9fc7-ca33-5737-85d7532b3d33@suse.de> <20230306161214.GB959362@mit.edu> <1367983d4fa09dcb63e29db2e8be3030ae6f6e8c.camel@HansenPartnership.com> <20230309080434.tnr33rhzh3a5yc5q@ArmHalley.local> <260064c68b61f4a7bc49f09499e1c107e2a28f31.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: Luis Chamberlain Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org On Thu, Mar 09, 2023 at 03:49:50PM -0500, James Bottomley wrote: > 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 ... Advocacy for using meaningful values is a real thing, Dan Helmick talked about this at the last SDC 2022 at least for NVMe: https://www.youtube.com/watch?v=3_M92RlVgIQ&ab_channel=SNIAVideo A big future question is of course how / when to use these for filesystems. Should there be, for instance a 'mkfs --optimal-bs' or something which may look whatever hints the media uses ? Or do we just leaves the magic incantations to the admins? Luis