Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3110705pxm; Mon, 28 Feb 2022 12:13:40 -0800 (PST) X-Google-Smtp-Source: ABdhPJzgXhbACOxHDfsJL4E15PfTfBKDrbvripSKEFHOgv33A2GAdSQ5EBD1F50Ryqk/DujPMHtF X-Received: by 2002:a17:90b:11cd:b0:1bc:4948:39c3 with SMTP id gv13-20020a17090b11cd00b001bc494839c3mr18368724pjb.41.1646079220623; Mon, 28 Feb 2022 12:13:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646079220; cv=none; d=google.com; s=arc-20160816; b=ffaaOLuWfBUHoegB3D0fTQPX3o89BjM9MzlAFZbFrtk/FzRocjwWq2b5obYiGavMlN NT0xms3p9qS235jYM8amW4MonODkQg6lqzYrxbF7EFkNOESH4cUDgjKofuLARRqjoPJk csdz8f6+HtotiWa3cxiNfEBDn7/CVY8xGC6zay6qA5uNbdIc6UYrLX/WXe5B82n4DMnb xGhs3XOv+zh6Mwoa7cSiCWenJSa0KftY0+lvm6ygd8OCVe7DUNZAHVj8gQ/RZtNzWWeg UxZilVVJATUMC+pBh9C1na3uOHtbTRDJbwoU20OqLhsDb4DrHpIPG5mBfm6QRirxZHBF cgqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=kCtGvMvWLp2LLzrDiArxgydyhNmyvgnQpxTInHfQxDw=; b=AD4Oc76+YkPQuHZkKWpj0ZwFI8qERFkFP2Yt8rJjUf22k2Mj681Smzj5AoOrwe5PWB VmpRrXMM1dQmexsasI0yBeEqsxGJeEg8F4pf1cIe2IjWVDUuPkaTCywpCQjfMGcGJnOC eNlQzWFfvqYlsAchZeBDEOQwWY8f8HvazrfO5USi8Ss7NZB0A9tDjaCVFrnXMUTNJjXL 6lEU1YEkXDJp8Z+zkhXxkdC5MeKMBYLvcTOclt5sFJ42gxsIDEIJH/ZHECA0hUYAyeTM BSqQ3RWnYgEDF+5qIDdFp/NVlETHYvgLyuphjuKWlFHi9imPmHZnuJSeAp7Uui4iapmf 5E3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kgMIFp0k; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [23.128.96.19]) by mx.google.com with ESMTPS id n6-20020a170902e54600b0014ce5b1dbbbsi11517909plf.228.2022.02.28.12.13.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 12:13:40 -0800 (PST) Received-SPF: softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) client-ip=23.128.96.19; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=kgMIFp0k; spf=softfail (google.com: domain of transitioning linux-kernel-owner@vger.kernel.org does not designate 23.128.96.19 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 5FA5E15F629; Mon, 28 Feb 2022 11:36:18 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237450AbiB1SPh (ORCPT + 99 others); Mon, 28 Feb 2022 13:15:37 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44936 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240642AbiB1SJG (ORCPT ); Mon, 28 Feb 2022 13:09:06 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5343B5E76B; Mon, 28 Feb 2022 09:48:52 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2A73860909; Mon, 28 Feb 2022 17:48:48 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 30B00C340E7; Mon, 28 Feb 2022 17:48:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646070527; bh=Ld3mo65E0/KE6WkoUpUGYPKrTJ2wuyv9AoP0+dIK3uc=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=kgMIFp0kd/C9EHZyMqDnv/UGSujzmye9vKg2DGryvxJhA6kO45qy4fwDsgY0XrBF1 JNGUCmYJckv4sAzDWI5ryCB+3OqN/0a7y5kwL1rKK2gOpBh9K01un81IGEMEY1J7MF xlIT/FGBRJzG3MwkI+KiNENV5+DljzL7DSs6oRG4= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Filipe Manana , Qu Wenruo , David Sterba Subject: [PATCH 5.16 139/164] btrfs: defrag: dont defrag extents which are already at max capacity Date: Mon, 28 Feb 2022 18:25:01 +0100 Message-Id: <20220228172412.565652216@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220228172359.567256961@linuxfoundation.org> References: <20220228172359.567256961@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Qu Wenruo commit 979b25c300dbcbcb750e88715018e04e854de6c6 upstream. [BUG] For compressed extents, defrag ioctl will always try to defrag any compressed extents, wasting not only IO but also CPU time to compress/decompress: mkfs.btrfs -f $DEV mount -o compress $DEV $MNT xfs_io -f -c "pwrite -S 0xab 0 128K" $MNT/foobar sync xfs_io -f -c "pwrite -S 0xcd 128K 128K" $MNT/foobar sync echo "=== before ===" xfs_io -c "fiemap -v" $MNT/foobar btrfs filesystem defrag $MNT/foobar sync echo "=== after ===" xfs_io -c "fiemap -v" $MNT/foobar Then it shows the 2 128K extents just get COW for no extra benefit, with extra IO/CPU spent: === before === /mnt/btrfs/file1: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..255]: 26624..26879 256 0x8 1: [256..511]: 26632..26887 256 0x9 === after === /mnt/btrfs/file1: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..255]: 26640..26895 256 0x8 1: [256..511]: 26648..26903 256 0x9 This affects not only v5.16 (after the defrag rework), but also v5.15 (before the defrag rework). [CAUSE] >From the very beginning, btrfs defrag never checks if one extent is already at its max capacity (128K for compressed extents, 128M otherwise). And the default extent size threshold is 256K, which is already beyond the compressed extent max size. This means, by default btrfs defrag ioctl will mark all compressed extent which is not adjacent to a hole/preallocated range for defrag. [FIX] Introduce a helper to grab the maximum extent size, and then in defrag_collect_targets() and defrag_check_next_extent(), reject extents which are already at their max capacity. Reported-by: Filipe Manana CC: stable@vger.kernel.org # 5.16 Reviewed-by: Filipe Manana Signed-off-by: Qu Wenruo Signed-off-by: David Sterba Signed-off-by: Greg Kroah-Hartman --- fs/btrfs/ioctl.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1020,6 +1020,13 @@ static struct extent_map *defrag_lookup_ return em; } +static u32 get_extent_max_capacity(const struct extent_map *em) +{ + if (test_bit(EXTENT_FLAG_COMPRESSED, &em->flags)) + return BTRFS_MAX_COMPRESSED; + return BTRFS_MAX_EXTENT_SIZE; +} + static bool defrag_check_next_extent(struct inode *inode, struct extent_map *em, bool locked) { @@ -1036,6 +1043,12 @@ static bool defrag_check_next_extent(str goto out; if (test_bit(EXTENT_FLAG_PREALLOC, &next->flags)) goto out; + /* + * If the next extent is at its max capacity, defragging current extent + * makes no sense, as the total number of extents won't change. + */ + if (next->len >= get_extent_max_capacity(em)) + goto out; /* Physically adjacent and large enough */ if ((em->block_start + em->block_len == next->block_start) && (em->block_len > SZ_128K && next->block_len > SZ_128K)) @@ -1233,6 +1246,13 @@ static int defrag_collect_targets(struct if (range_len >= extent_thresh) goto next; + /* + * Skip extents already at its max capacity, this is mostly for + * compressed extents, which max cap is only 128K. + */ + if (em->len >= get_extent_max_capacity(em)) + goto next; + next_mergeable = defrag_check_next_extent(&inode->vfs_inode, em, locked); if (!next_mergeable) {