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 3A307C678D5 for ; Wed, 8 Mar 2023 17:53:28 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 8D31C280003; Wed, 8 Mar 2023 12:53:27 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 88263280002; Wed, 8 Mar 2023 12:53:27 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 749EA280003; Wed, 8 Mar 2023 12:53:27 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 698C7280002 for ; Wed, 8 Mar 2023 12:53:27 -0500 (EST) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5BE7D140C0E for ; Wed, 8 Mar 2023 17:53:26 +0000 (UTC) X-FDA: 80546478012.25.0158A7A Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf27.hostedemail.com (Postfix) with ESMTP id AA17C4001D for ; Wed, 8 Mar 2023 17:53:24 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dUylDDe8; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1678298004; 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=r5HUmBD7uXqC5GBdmL5+Ug922V53os294l+QgA1lLLI=; b=lwpoXuTQdadAmV0N0vC/IlVEmrkJMN8TnqiHyqoWqCQPF+mMtoUO7ckrPoTVxvXtx0ycHs d/JFZWDssygoE9MtmxN+FhwRe17ZmvGGIGRi07rY07M/thyAOsNX0mghAltQZ1gdC3VsD8 K5S80Ev1lknuQqemKjUJXKW/Ap62VC8= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=dUylDDe8; spf=none (imf27.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1678298004; a=rsa-sha256; cv=none; b=SNfg+/8k7Um+KysajIfDgYpObYr5tA8qiZnnYQ1riPH04NxjVeRYi1aveHxWNwwyd4DpNr itDMxVfGCPnKBmBFdnSrhbMkEAROFJYRcwmQVNE7zmCmsmh6lLNV0STonqkUJVX2+GAGA9 rYfc20JbOdSLVz1kO0XT/wvEQwLTDHc= 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=r5HUmBD7uXqC5GBdmL5+Ug922V53os294l+QgA1lLLI=; b=dUylDDe8zVqohTKYCh+J7vZELc 0Tst8j6/bW3q6vDnowkyQ2dqeeJqpSQc5KXZIGhh1uhS4d7pA4Lxm9KhSxTl5fAM6oSx/FpT+EDsc Nlbx4uL6QthZ8yZzm2jaknbhMHrbh8cJY3VN/LHAC1mTwkRMEIZVPFHWZKfgz2p/9oCXfar86d5Ou m0yzyOWD9Hcc/xCIAFTsm+5711/S9tJ5ZMpDhuwb9CvKU8L10umHdZ8371hH2Ov+S+tbVh566YcMs DNO23cIPiBMPsGaE3JZgcYR1FT85POjvJI4lb2/T5V8U4DNc5UisvzqPNu5a06iytSEizvFBcSJr1 myp1iN9w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pZxyQ-007b7x-Gj; Wed, 08 Mar 2023 17:53:10 +0000 Date: Wed, 8 Mar 2023 17:53:10 +0000 From: Matthew Wilcox To: Theodore Ts'o Cc: Hannes Reinecke , Luis Chamberlain , Keith Busch , Pankaj Raghav , Daniel Gomez , Javier =?iso-8859-1?Q?Gonz=E1lez?= , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230306161214.GB959362@mit.edu> X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: AA17C4001D X-Rspam-User: X-Stat-Signature: outssmibh9c3x99c1833c4mjtacmcd9q X-HE-Tag: 1678298004-310138 X-HE-Meta: U2FsdGVkX1/Pp95ObqW0tgFSz4lnVJOBDn4qfb5JWOGeauMOGjyRX+pk3Fa+izoXUa3zj0ZWMtC+DuKKYsPOR4tyDp0lMQbxMcGXauTZldKOQFxGsBQcqHSOJJmVRnm93+dI3P4Tmin9ubC0AasN3Y+Zt9X5wMh6DWYOCXGD+gHCf8c1v6oOI4hK+UTDWkX5vDIvQY12WDXbFdgsKPQXcvPgewjZn3gqaNTpcLjTxMzAoAqAnkZqnJwt5zYtQrFacYuw1oIkeYMF10afbmnYlQH6+NapB8ScTDkhCovYXFesZSDarYPC2OTJ8v0kkmkQzeDMhqZWS5j5hrWpR/SViviCCjful9dC2Oma4fpcWHN5SwX5nmW/sZkxuxmEK7Ebf3UoDOPZ0xGjXrbjQST62fJL0MXARqAMWUvlW5DDas+sNDvNcn1whHfF6mJRt7qp5eckEdQFmX3kAaw1JUr+/5Z1PeB34PeXTF81GPXnCUNjNgVzSlbbzPPuybrdC22P0MGEuwQqA5+j+4akUr/TfEebhUK9A/WixRADBZDhyVsg7glaE4cyHrntBp5GKmzAik8+J3NvYhklzIhi+zOmjpH9TPlgmPLNLORAr3/MHRxsFBwqFgpTacR3wSXyWZCHdGqR5v+DmRRuqBD4XEHNdJGTk5GzsPx20G/EUqygw67qUSuWnCjEzE3lngSYNe2JUwYcfMTJqumpgATvVQZIkvv/vfkdVj2rbROVzXUJ1vFDqsu5CNJyi3WyMdd0gEjg2/LA9ni5r12gZpWv35nZ72vYk6P4nFyOpaNGFKTS2EKbFBQ8l2Ys8ZaSEhxMnA1OC/JdN/3TCrJojViVaapwZDWF8V5rupYyMkp6LVMfQ+BVvgusfbXCyehRXZeAlkMsgUYbk9KLJaorRWMpR0aVAE0NvGbZiZynRmNzEk2IpEXxxGzu7lhShlpPvyNpqh4rfmqrlljC9j1pvQjY5p3 6ryRAWI+ gen0dcNZkfw7CtAhoCuG3hZ53a3x2UQ+WJApm+MaKC5beizaf/htV0A9+QiSWUdXEjI43PiVjTcFmgX5bQ+l7mCCzlaIQJxPf830QTSyL9WG8kU2w6btgsnBNXIsx3ar6IhKu4JIFbeR7DrZF8Qq5QHccrg== 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: On Mon, Mar 06, 2023 at 11:12:14AM -0500, Theodore Ts'o wrote: > What HDD vendors want is to be able to have 32k or even 64k *physical* > sector sizes. This allows for much more efficient erasure codes, so > it will increase their byte capacity now that it's no longer easier to > get capacity boosts by squeezing the tracks closer and closer, and > their have been various engineering tradeoffs with SMR, HAMR, and > MAMR. HDD vendors have been asking for this at LSF/MM, and in other > venues for ***years***. I've been reminded by a friend who works on the drive side that a motivation for the SSD vendors is (essentially) the size of sector_t. Once the drive needs to support more than 2/4 billion sectors, they need to move to a 64-bit sector size, so the amount of memory consumed by the FTL doubles, the CPU data cache becomes half as effective, etc. That significantly increases the BOM for the drive, and so they have to charge more. With a 512-byte LBA, that's 2TB; with a 4096-byte LBA, it's at 16TB and with a 64k LBA, they can keep using 32-bit LBA numbers all the way up to 256TB.