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 46DEDC43217 for ; Wed, 5 Oct 2022 19:49:34 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230242AbiJETtc (ORCPT ); Wed, 5 Oct 2022 15:49:32 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:46810 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230221AbiJETt3 (ORCPT ); Wed, 5 Oct 2022 15:49:29 -0400 Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A3F637F25C for ; Wed, 5 Oct 2022 12:49:26 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id E3B5E5C01C4; Wed, 5 Oct 2022 15:49:25 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 05 Oct 2022 15:49:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bur.io; h=cc :content-transfer-encoding:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm2; t=1664999365; x=1665085765; bh=BO 1+CiMC4oqAmR5mpTyhYgLTfZF8TEoQLLolW3UFqOA=; b=DyAAi7W6SMoHK+PLMJ NO7u5ePKGfMxtMsHWlat0lqXofnb4e/yDjF7m7vZqLQ2KoCywxdX8VAfvvZJLoU/ bOHAqVqZwXYcW6ZJIgzz+QFI4Q8hBsA3YuwRavxFxWp2iUXj+Dm2RdpUjEZc7sMG 4ZsEHSTxvmaXmzgL811gdt1RTQ8Iwk4XkkXjuUNKODYIxLBeRBbwwWMxI7Juowdi SyE/j6WB3+vkFlZb3F2kGZVoWIC3Avf4EwQaP56VMvLz+1QzXYpG/BrXnJvy+VPB 1jt8wK20Dh+E2I72FlRWqZyt90r7fGya6ytQFl9C5Mg0ihMzdPOEEip3EdZWswUE yKAQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; t=1664999365; x=1665085765; bh=BO1+CiMC4oqAm R5mpTyhYgLTfZF8TEoQLLolW3UFqOA=; b=J213dAaUlKt3SgAtIYgQ6fuT0SKRc NtvaX4CuiuiC9PmLscooslbwca6Q3FHCdBmheDZWAu7pufIM0qzoqN0t+iQl1AUF KreuJw0TzvxLgDdwq1OKpp4driJunXBtRDoZ9LsrnL4kBwRuu0tGfrpuUaOrarHV 3cSwZn0NO+ly257oOibsPno+EdLUbUwJ6lElTRmxZtYmroq9hgvK9IjfR224JJ2h lGjs9p6tOxqUzfxClK7iUQmjmMqejemt6E5m81A5zP0u8e40ynhq0dLzusgbKfp7 xjnJVbk6vdXH+4V014Z1AW/PwaBocS8sCoVH7jXmAeL+SgCVgBTwV5d2w== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrfeeifedgudegtdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkffojghfggfgsedtke ertdertddtnecuhfhrohhmpeeuohhrihhsuceuuhhrkhhovhcuoegsohhrihhssegsuhhr rdhioheqnecuggftrfgrthhtvghrnhepieeuffeuvdeiueejhfehiefgkeevudejjeejff evvdehtddufeeihfekgeeuheelnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghm pehmrghilhhfrhhomhepsghorhhishessghurhdrihho X-ME-Proxy: Feedback-ID: i083147f8:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 5 Oct 2022 15:49:25 -0400 (EDT) From: Boris Burkov To: linux-btrfs@vger.kernel.org, kernel-team@fb.com Subject: [PATCH 1/5] btrfs: 1G falloc extents Date: Wed, 5 Oct 2022 12:49:18 -0700 Message-Id: X-Mailer: git-send-email 2.37.2 In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org When doing a large fallocate, btrfs will break it up into 256MiB extents. Our data block groups are 1GiB, so a more natural maximum size is 1GiB, so that we tend to allocate and fully use block groups rather than fragmenting the file around. This is especially useful if large fallocates tend to be for "round" amounts, which strikes me as a reasonable assumption. While moving to size classes reduces the value of this change, it is also good to compare potential allocator algorithms against just 1G extents. Signed-off-by: Boris Burkov --- fs/btrfs/inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c index 45ebef8d3ea8..fd66586ae2fc 100644 --- a/fs/btrfs/inode.c +++ b/fs/btrfs/inode.c @@ -9884,7 +9884,7 @@ static int __btrfs_prealloc_file_range(struct inode *inode, int mode, if (trans) own_trans = false; while (num_bytes > 0) { - cur_bytes = min_t(u64, num_bytes, SZ_256M); + cur_bytes = min_t(u64, num_bytes, SZ_1G); cur_bytes = max(cur_bytes, min_size); /* * If we are severely fragmented we could end up with really -- 2.37.2