Received: by 2002:a05:6a10:9afc:0:0:0:0 with SMTP id t28csp3119875pxm; Mon, 28 Feb 2022 12:26:39 -0800 (PST) X-Google-Smtp-Source: ABdhPJzfjh8t7W0Xz/t0BjgFg8CBkCgL+GKxYM6Q8J/ajWPE0B4133/4Htu52pizHqsOvCfgMJA8 X-Received: by 2002:aa7:9688:0:b0:4e1:aee6:45a3 with SMTP id f8-20020aa79688000000b004e1aee645a3mr23613860pfk.12.1646079999072; Mon, 28 Feb 2022 12:26:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1646079999; cv=none; d=google.com; s=arc-20160816; b=KYtDJpjWOa/ZX6niPcIU4DX0crb6pBsvbq3fsssdoimSw2THVn1tu7XyeoqnkOlO9x /OEV3YwRva+7qD47qEVZgKyFqDusSu/OyCZnwp26m3trXrIbvSjJK/DyGdUiZzpsZAKd yGYDnqrZ6tfCAJhPFIOZEmM26T7K6Q3gXkuFGmgtWH9yFARdwFAbmgdZR3KX6cAFa6j+ eWzxkcyO3BtZmfkfyb48nQm0bwI+AAouqY+mL8wNzQUHmNqkwcDwntpchDZB43Ph7VmK cwXG3Y5gz2Y3pzC5Pv3aFCkzQJqppARhGZO33IKJMWLu4Fqqas5TbkufLK4GN8VEWK4z bCEQ== 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=RCqPSfZnDWPolNx5KX6YRakPVxucZi4OZ7JTJEJhTHA=; b=sgQcRLe+V81kYszLDKjU4vwUnoREhzsq+hfdQBPnEGoNfK1wTrOLMWJ0v09mYmdavE AlM9Ua2r/luCqi0ZHMiJPOl6WTCUsj3mVOPyVasVs4gZTdKNlfjvtJLdDHDNtdiFS6WN QZJG+RIuRHO7ZC1HgVTsENFLUArwbY5Rh2xGHWNtPrr4UvGiqH3Zd9Q3qD6uwUvDzJlS V0CF1Cg4yM+OIeZL4mJHyKgrsuWoOMAt16zkmii4GiQgZ+tkfmcihb+U3jy3oIKFFPzU ClZfwhi2fVPGufX4dZDogMmVkUszWUjDrqZrpi8OMGFVJ+LxGqnDFHjavyCNfVFELjBY RdXA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=z45BKJeP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id bc15-20020a656d8f000000b003744ea02901si10496086pgb.872.2022.02.28.12.26.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 28 Feb 2022 12:26:39 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=z45BKJeP; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 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 12D2A1E6EAB; Mon, 28 Feb 2022 11:44:10 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240144AbiB1SNO (ORCPT + 99 others); Mon, 28 Feb 2022 13:13:14 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40610 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240847AbiB1SJN (ORCPT ); Mon, 28 Feb 2022 13:09:13 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 25F475FF09; Mon, 28 Feb 2022 09:49:11 -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 8CA5360BBB; Mon, 28 Feb 2022 17:48:42 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id A30A1C340E7; Mon, 28 Feb 2022 17:48:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1646070522; bh=Q8JC4OcwLGjsXfqJrcQWbcSisgO3H+o0nNhmi2ygFr0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=z45BKJePhzkIoKV6aYtLh2aYTeKhBPPx8cZhxis73YJ0BjaFmoc/1p0F8g+GcwqfQ tu30+BX5VjwSTeDCoV8r2M97IzlfWadzAeHGeKMRPxRkBGnx9wzJ1y5rbD2rZluczH A25EF8GwJgO75uDprJK1cp+TcRHN9DLBhaN/8q2w= 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 138/164] btrfs: defrag: dont try to merge regular extents with preallocated extents Date: Mon, 28 Feb 2022 18:25:00 +0100 Message-Id: <20220228172412.488282193@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 7093f15291e95f16dfb5a93307eda3272bfe1108 upstream. [BUG] With older kernels (before v5.16), btrfs will defrag preallocated extents. While with newer kernels (v5.16 and newer) btrfs will not defrag preallocated extents, but it will defrag the extent just before the preallocated extent, even it's just a single sector. This can be exposed by the following small script: mkfs.btrfs -f $dev > /dev/null mount $dev $mnt xfs_io -f -c "pwrite 0 4k" -c sync -c "falloc 4k 16K" $mnt/file xfs_io -c "fiemap -v" $mnt/file btrfs fi defrag $mnt/file sync xfs_io -c "fiemap -v" $mnt/file The output looks like this on older kernels: /mnt/btrfs/file: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..7]: 26624..26631 8 0x0 1: [8..39]: 26632..26663 32 0x801 /mnt/btrfs/file: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..39]: 26664..26703 40 0x1 Which defrags the single sector along with the preallocated extent, and replace them with an regular extent into a new location (caused by data COW). This wastes most of the data IO just for the preallocated range. On the other hand, v5.16 is slightly better: /mnt/btrfs/file: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..7]: 26624..26631 8 0x0 1: [8..39]: 26632..26663 32 0x801 /mnt/btrfs/file: EXT: FILE-OFFSET BLOCK-RANGE TOTAL FLAGS 0: [0..7]: 26664..26671 8 0x0 1: [8..39]: 26632..26663 32 0x801 The preallocated range is not defragged, but the sector before it still gets defragged, which has no need for it. [CAUSE] One of the function reused by the old and new behavior is defrag_check_next_extent(), it will determine if we should defrag current extent by checking the next one. It only checks if the next extent is a hole or inlined, but it doesn't check if it's preallocated. On the other hand, out of the function, both old and new kernel will reject preallocated extents. Such inconsistent behavior causes above behavior. [FIX] - Also check if next extent is preallocated If so, don't defrag current extent. - Add comments for each branch why we reject the extent This will reduce the IO caused by defrag ioctl and autodefrag. 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 | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) --- a/fs/btrfs/ioctl.c +++ b/fs/btrfs/ioctl.c @@ -1024,19 +1024,24 @@ static bool defrag_check_next_extent(str bool locked) { struct extent_map *next; - bool ret = true; + bool ret = false; /* this is the last extent */ if (em->start + em->len >= i_size_read(inode)) return false; next = defrag_lookup_extent(inode, em->start + em->len, locked); + /* No more em or hole */ if (!next || next->block_start >= EXTENT_MAP_LAST_BYTE) - ret = false; - else if ((em->block_start + em->block_len == next->block_start) && - (em->block_len > SZ_128K && next->block_len > SZ_128K)) - ret = false; - + goto out; + if (test_bit(EXTENT_FLAG_PREALLOC, &next->flags)) + 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)) + goto out; + ret = true; +out: free_extent_map(next); return ret; }