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 0B067C678D5 for ; Sat, 4 Mar 2023 16:47:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 34F9E6B0072; Sat, 4 Mar 2023 11:47:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2FE326B0073; Sat, 4 Mar 2023 11:47:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1EDFC6B0074; Sat, 4 Mar 2023 11:47:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0C4A36B0072 for ; Sat, 4 Mar 2023 11:47:41 -0500 (EST) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 339B3802DB for ; Sat, 4 Mar 2023 16:47:40 +0000 (UTC) X-FDA: 80531797080.07.8BA7348 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf11.hostedemail.com (Postfix) with ESMTP id 809DE40008 for ; Sat, 4 Mar 2023 16:47:38 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Vh+9EUwy; spf=none (imf11.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=1677948458; 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=LhoupYTBTqhNMehhFdXz/ehBXFuYtg+7HM1T8ayiyDA=; b=qd2Kwlt8+cX8lXa7wvSy7LnyI7CYJMXyKLqiWn95dALBF+ktvpp4Ft61KBnue0EXi+eSy7 azoCJRXZFlE5DzMvgBotV3VF6oKA9b6xzSMo2d0SsrH5MLTMxIDGN7uvI5tAaUiA28SnNN qhlSwwqsHuEr6vWIUVjrxRXRfM45YiU= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Vh+9EUwy; spf=none (imf11.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=1677948458; a=rsa-sha256; cv=none; b=SfVFs3kncxJjLXN2LmGrgmvk8zQ9YcG+tb0gagWfDOFUdUV8qjl8K/yrLb67S9Vsf53oOo 6G/yedJ+VDcc79z/qVGQPzkWQCMPR0ci8Eb+O6AYDHWDN/ABW9KSyRRvI4RZMLp+DosTDS jOai7k2QH+ts9B7rUFYm/PqJSPIc/Hg= 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=LhoupYTBTqhNMehhFdXz/ehBXFuYtg+7HM1T8ayiyDA=; b=Vh+9EUwykwSYU0et0b9yjnFoNO 3ytJOYHrsVUqNjGm4n7LbJg4RYJlZjzGkws+fFo/5J6xrNbeJBLruxzZSLq1hSDA/SHfUEYPnLqPf z0t2Jvbjcjjd+rMitbNjWrF+2AiqqHvuBWlmo/f1a5AoYuRL203hzKyaSwkNiJ8/SNczCU8tpPs0h mXJJo5FwLrov2rucArIQh1jhHOWsFLvFKejZ/m8f6Qd6l0rBF8bUiE5CIK3gcoxefn+X87xjo309z /8s9CTjp0luhyuyfb3+S0xO7jJheXrBrYHDpT0PR7vXYiFEsg9c9+uAoCOLX3z1pSog9RXY9Fi2Ia 6qKyJrmQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pYV2b-003wXb-1X; Sat, 04 Mar 2023 16:47:25 +0000 Date: Sat, 4 Mar 2023 16:47:25 +0000 From: Matthew Wilcox To: Hannes Reinecke Cc: Luis Chamberlain , Keith Busch , Theodore Ts'o , 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: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 809DE40008 X-Rspam-User: X-Stat-Signature: bzxaiqpmoef5j5ozkbi8gfcors8frao4 X-HE-Tag: 1677948458-417262 X-HE-Meta: U2FsdGVkX18oW78C2x7pQHStDMmw+emzpwhWeZJAWyWqkZJu1nviOotDKeKNRBoV/8fO9B68JlZG/5C1T/7mOoC1Z2PrbfdxRd7PsLoOCxJCeuWrXQkF+0Yysk2oD9jm12qanr29/57pPcuehyjT4uB6qS4Fcc8Z2vULwLtvR+yL3+qrf8hvPNvSSTV/aCO03/aAC1FzfB1U28AkmJ6Lo/z9C1T4+RlUj8tW7XSBzuP7jyW4NUvF+5m6tz1ApbXNelBrMaGuXijKEQjvhxoRIiiM5GpryVlffeqUf5pnQFrhjHDfHf4ncFWUxgbeGk8Ed/+yQnyypaIHQ3XrXySgxg2wEcZ/HWyW6gQVg4pxbcDvcwIpxQToXetWNa3XF82tQoI1zcDJ9NJvGMFKHkSJSYyrXMY5tqOL6P3o3I+UPQG/7S0cYwInUfUAy5SHnisHTyQ1+vpufzNYULjmNEtEzHkssYOAR8lS5pYlPZdLXCZV6LigaJHmNk8ThzD7HFfGUSDMxwEG31FEIJmNCFiR9bvqY/Q/T7ufHU1368vREcIF2CP+hmDENeT85rVq6e0RzRnPlkS+5+PWcDbM6Jnqpe8Rrwf/1qvU9pFUXL+U6Twew2i7wVLY1Y1fiS87PdmB1IfmHeOJHzt8N1nJCchi72Q0p/ukciGlEnMU6oCBxb2JiJbX4l8fT1qu9oKDJbiuzKKQsYUE1b8U4LZCwjmfI3QAEl0McMBSqenZ1TAbjjVyYZ+GLCZ8vqNMcjMioV/XFfYE34/6A1olEz96Fw5gvMlJpGw+QXIg5qJYS2fPeJoUaNUXJdbpwI29KHn0JHhoCFpyKDsTM3wcDa6V8JC62eu3y1ytBWW/+VTjVGfr+nxa6cQievMMeC2YQv5h0sUVVY2bF5xMKSJMBTC8nPsllU8gzJVOCvPkmcP+nugMIGQROdKtW9flcKw2f5vK5zMIOqkeHa5v+ObrjvdyOJZ z6nX6v4w 8s41feuB3PboCcMnuryPc+vhRvBoxzLMpDFpaZ5yQ6BXhoITh1gPSGVffDAYXOHTnKADiZYfHz4q/vI4i2uQiP4SInAvIo98pFoEh9Mf6VHWKnpnFX6BHa2VFWicq4GAU4yC1D68yZQ10STBAyGpdjL8rjQ== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000183, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Sat, Mar 04, 2023 at 12:08:36PM +0100, Hannes Reinecke wrote: > We could implement a (virtual) zoned device, and expose each zone as a > block. That gives us the required large block characteristics, and with > a bit of luck we might be able to dial up to really large block sizes > like the 256M sizes on current SMR drives. > ublk might be a good starting point. Ummmm. Is supporting 256MB block sizes really a desired goal? I suggest that is far past the knee of the curve; if we can only write 256MB chunks as a single entity, we're looking more at a filesystem redesign than we are at making filesystems and the MM support 256MB size blocks. The current work is all going towards tracking memory in larger chunks, so writing back, eg, 64kB chunks of the file. But if 256MB is where we're going, we need to be thinking more like a RAID device and accumulating writes into a log that we can then blast out in a single giant write. fsync() and O_SYNC is going to be painful for that kind of device.