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 616D1C6FA9E for ; Sun, 5 Mar 2023 04:16:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5DCB46B0071; Sat, 4 Mar 2023 23:16:02 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 58DFE6B0073; Sat, 4 Mar 2023 23:16:02 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 454C96B0074; Sat, 4 Mar 2023 23:16:02 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 31F9A6B0071 for ; Sat, 4 Mar 2023 23:16:02 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id ED5F9807B5 for ; Sun, 5 Mar 2023 04:16:01 +0000 (UTC) X-FDA: 80533531722.16.99B6877 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf18.hostedemail.com (Postfix) with ESMTP id AA2691C0009 for ; Sun, 5 Mar 2023 04:15:59 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=eoNxFie6; spf=none (imf18.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1677989760; h=from:from:sender: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=XZbX19UIOBgbhN58Zf8KUMwb/xPxPMAlTovGZ1xqlvs=; b=KdeXxNO8+B8at9D4vz/PwMFzpOq+pjB1U+sFWLAnQfmajCSdtqbWuNs/E1QE9mv2+seADW xcNDqeOWo0tU4MAjQwi/bmvnvjgQZWHk63oFt5ehjmbCBpQYUlCAYoGJ3JPJESmcx7CZi8 iEYCi0FSMXmFH1yMyQgvHAPgIbWw/DQ= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=eoNxFie6; spf=none (imf18.hostedemail.com: domain of mcgrof@infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=mcgrof@infradead.org; dmarc=fail reason="No valid SPF, DKIM not aligned (relaxed)" header.from=kernel.org (policy=none) ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1677989760; a=rsa-sha256; cv=none; b=pkwV5ULziPyUhpCCZ/BNlvhvOe9QIywCV29ulDd7kscdxveJAg/JMMFPGHHkMO3A9yqwZ5 VdeHYl6BoqhfP2nbvsfpAGvfR2qirifIjmrGa6/NyoHRFnwmHUVzIgu0g3+JTtZeS3xw+R wEgLHhI4CYt2js/YmMMTD6fn0+YDga0= 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=XZbX19UIOBgbhN58Zf8KUMwb/xPxPMAlTovGZ1xqlvs=; b=eoNxFie6n2xBw64ti9CbXcM2xL b0tb4yBx1mASTimsEwuaE758mUlXj0hEmnHDU2dj/elmN9DbkLstJgAgR3e+kst9kv3URQWRoDWZE 06LKnkGW0QhvxRpFo089uUxTUYPnvHkeU1miaROA4/8+TQ98LOjYdY+RFh1Nk3WEbijwDX//YySRx B3F/NSY1sBL+YFhewXkzurfqHiYWweaL7i5sYbscaNfolaSTYtBMWrARValsEG1JFsYWICNhoYDQs 3hBQyhQjoeNEbTfn2xqS6DR0Hsr5adK8swmnzUFy8n2c1bQ8KA/LK42GDzBuPkBO0YNH1aWI6/Fi4 jh9FtPpQ==; Received: from mcgrof by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pYfmo-009oHB-LR; Sun, 05 Mar 2023 04:15:50 +0000 Date: Sat, 4 Mar 2023 20:15:50 -0800 From: Luis Chamberlain To: Matthew Wilcox Cc: James Bottomley , Keith Busch , Theodore Ts'o , 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: <2600732b9ed0ddabfda5831aff22fd7e4270e3be.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam03 X-Stat-Signature: qp57n3ew3nf17bkzorok4itycr5j1i4n X-Rspamd-Queue-Id: AA2691C0009 X-HE-Tag: 1677989759-74470 X-HE-Meta: U2FsdGVkX18/VrAeWzjY7K8QJFnenwB1nF7KfzD8pZrV8FER9xO4DIV/d3iA9V4eshDAGkLLmLghdv4CNTpkKY0/i0Nm+yFbmn3aMec/bIeB/mL3M4hIknIK0mZ2pESPgnpnMdvTRCAyvGHK92940FuSAzx1lgdalrCV0+1fcyv6+HrPjqqjVfhf7cCfHosJTtpBOFt6RA8C45WCjLtpGacHWzGfIBfnsglq0k4rglTSkMzebyfCdz9CulqJAHLpq6oDuaeCKdaxK6xK/Slh4waSRNIv9gRJMfNkeGNY3UXir+jaTaJvoS+Ds9iz3p7/1ay2qMzQ4x0Adpht5TXR31v42gCUPaDCKSg80Wai9UR5K4KZgGd70CY/+Ypf2TON/d/I4h8Sd8OUBBaY7gBLO3IOnAFnB7upDv0EaFZum6yt+FptForSvyoe3yUsKDPS4JHS67DF3mOPN2xWcl0ZCo4S00yobjptzgvXoB+JoPyMY0FqvxBEpaDFDjnVP/pObh1rbeKNRp8OaXvndnMLNbL6VQGJZ8zGLvBmGs4ym6aYc/xUTErIi3mRDrz3Q720zHp6Fy/F0riwr/oNQZbpO+zn7QM/3K0bxah2UyTvrG0Sndwq+EaRmlfJhuOPX3Z4pkaVT3vIqpYYIn8jkEOTG9PeH7Z4ByM6ii2JtZi/PwL1fxNQTlLBGGPLYFmp0eAdVQvxgylz9KOOs4oFFtx6/ijprev1pdYLhcp8x9ipgFT5aheQn0Qg1YbVCR1uFKDOSjifsMK66Mlf8zuiFF+Imcu/tkD2um8uPTvB2Xe81MuD00SqU8BDXAgTrDwkkxXB0qXyCcnzVuJgDnSv++0HVxZHG3lsK+kpcWgogo88sDjrW/6veJ2Xavychzbki7/SvlfabyJcwiBYJHl5XwrN5kzC8HeZ38ShMHGD5stbb6MbGGPhN9ur4NR4cXsnOjFyXuRB/2oaNDlL84GyheH Gm1Sf7zh NZwktNVdBZnJlmIicsgzLjqbnC3wa/UlFmB2Aw+6BbOrq2guKdc1KWdxoXph/U6TL0/rvNPrNg+KULNG8O7wLtfaXWuMs2dwtPl3a4OT5jNZWEkgRqADdgWqjTo8u+t2z6gRhcnPjUBmteWHA6UViAbLau65lip8AvSnRLgL4yuLb060BdMxGd+7oX7KlKExyBsi7umStj0u6RS+Mp2HGPff/ssFFgrkkSU5GtKuqojVHNhnx4sPKL+c3lrFkPezuEWiaCVdY+sMsgdCeTr1jYdamwU8T88JGpV5j7hr68eS5fNuRgN9uNsDXZy8omlZ+AErM X-Bogosity: Ham, tests=bogofilter, spamicity=0.000484, 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 04:39:02PM +0000, Matthew Wilcox wrote: > I'm getting more and more > comfortable with the idea that "Linux doesn't support block sizes > > PAGE_SIZE on 32-bit machines" is an acceptable answer. First of all filesystems would need to add support for a larger block sizes > PAGE_SIZE, and that takes effort. It is also a support question too. I think garnering consensus from filesystem developers we don't want to support block sizes > PAGE_SIZE on 32-bit systems would be a good thing to review at LSFMM or even on this list. I hightly doubt anyone is interested in that support. > XFS already works with arbitrary-order folios. But block sizes > PAGE_SIZE is work which is still not merged. It *can* be with time. That would allow one to muck with larger block sizes than 4k on x86-64 for instance. Without this, you can't play ball. > The only needed piece is > specifying to the VFS that there's a minimum order for this particular > inode, and having the VFS honour that everywhere. Other than the above too, don't we still also need to figure out what fs APIs would incur larger order folios? And then what about corner cases with the page cache? I was hoping some of these nooks and crannies could be explored with tmpfs. Luis