From nobody Sun Feb 8 07:22:03 2026 Received: from mail-oo1-f67.google.com (mail-oo1-f67.google.com [209.85.161.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A0FB9274FC2 for ; Mon, 12 Jan 2026 15:02:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.161.67 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768230175; cv=none; b=tcTxE2KhRinvArA7QAUsLY02ii4axfJxmN4YAq3IqaB0r69eRUYpolF+hdRG2cTbufHnE5cJQXsM3A2nFe70gw5MpzHjZstOe1x4IyXxJr11rOpAg+9f3nGUWqsUVAzQkH0sMF05EGb41Juqz5F4NJyYbIWRnnl1CzP/8vrUNZw= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768230175; c=relaxed/simple; bh=oaj+1KQRb/TnihudJZJAP4TYRAcFQBAu10VP3WkIu7o=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=imtbsIEVUnAZ/FKwgunvZqO4KtG7IVTeNKSkD9PpKQb6VFdjyYKNI1aFRV5hUEPa5K8Don84flDhXIq5Ln703bnoPF4zOkMAXqEm3S3wtjTcepnV3WhOBnTL2yMDTvchuf4IRCAIwG7OlA/fKu6dWSc2mSOcwCmCfMe++Ypk1Cw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Vy8SUOPz; arc=none smtp.client-ip=209.85.161.67 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Vy8SUOPz" Received: by mail-oo1-f67.google.com with SMTP id 006d021491bc7-65ec86c5e70so3863766eaf.3 for ; Mon, 12 Jan 2026 07:02:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768230172; x=1768834972; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=kQbUZBlwnVIE/0tOVdzdzTy0LaUN1JEnxmyyVOiPwHw=; b=Vy8SUOPz+zy/BU43QGnC4VYKoiPsMyLhM3GPepeGlyY/plN82D3buH+8WX0ZXn1IrP EuTmwJowxEZJ0UanM75aw2Z+kqfjVKZkw1iBi+Z3TkR78vzh78t89W5UJlOBhkeS8BsC 0vD4bpQYgRMPiTKb5ja/NL9hYwn2oKa4Maj50JLYy0dn2+kIEa/qcik9qq3QHS6kPJBT Q84JhoWvAOD1Yj7e1N0ywOnC6W+aY5sKb2kAsco7AkeYLT6I3jXRLgUbrGn25b+wQ4qd UwdO1304sHFpKGrAeIm6WC81X5rdlXXKfI54J/amL+pEIRQVZBAWlFBwHcdR+OOlt5HP mnvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768230172; x=1768834972; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=kQbUZBlwnVIE/0tOVdzdzTy0LaUN1JEnxmyyVOiPwHw=; b=QnbnakTRkdONIlSMglkNo6kojXCAiGXeB62Y2pLZgiNFhN3lTR3g931Y8JGBUf+FyN PEMzddoxc0VJy/tut0syNMxrX2PRfvdcYhqkeFpbYDmqVPDw8I1QN7b9W9bPWzi/wKei XDw/qj/LX2n31SUtbxII2evKshC2hKZlrPdaEa17uOA2snu0WMpDWl5hTCFpw/SsuoZK 7Yk9/xjT8bpt7l8zB5sjxeYeZ08xLn6JWYQZ7LwhyPl3+xIK4DlL0pZ/wQZl+hLuDdbN ChffRYJDgD1TLcUeQPamxpLxhpq7rSq7Kd/viYTXA/dt4AR7DryURS7Hhve2vGDlzJ1z OPZQ== X-Forwarded-Encrypted: i=1; AJvYcCURGfTqzOKdTQ7zEmL7867HEzAgx3OwaFLDNY92EHCi2VRe2ITBcrGW0ZGSTI7xOk8lxDwRDZeSzz3zEx8=@vger.kernel.org X-Gm-Message-State: AOJu0YzQOqDhjxoufgCbTLS9wGcUZqmXIzKOMXBIAzTajiI8KEea7eyN OTsHS2Ij1YS6o/fpA7phJ91HrC8KnVLv1nDc+eckvpFw/KvogxkiT4n3 X-Gm-Gg: AY/fxX6h/PSYV2dmzHoWTzZqt0VVuS8cURFMEGQO7c7q4n8rm8EK5YTvAkrRNc3Mvbp TtxSI0kjYAU+gUkcH3Ik5TFH5UKiZqB2LCyutIkGFeRcE3Kk3NrCLSCFdzi3EVR0bZSDNzw9Fs0 z7keaJdm8sQVD68Ls7/Nk89uV+dun9WLtKCPCjFBv2CiTNhGM88V28eKQv6j8f1GiHfSFY1sXDi ZUQNdeACIanmld7+qrpzreFG5Z//FD45ydb8wP8J9S2nTbSBWd0d7QIGvETWwPbriP1wtXgA2/U aWwl3pj+SBMHygwL8gZkbh3oqUDFS4gAww583N+VMrnSdGc3r5rLYMSP3hF9IoZC4qsptY6eazM z4CbpQWE9GC0yk1Y1dIBs6YVi5o8g+ZQbzld0eIfgBLcQ1vsj7oHm6tPc/Im6umRdDvlXVc1917 ehdl1urhucQPbYQzhe4Fh6406vZb1TkCiO X-Google-Smtp-Source: AGHT+IEQFur2qhGuoz2oKzCG1BeyVo4cXFujy/+8zzGLBZM+Y/h+R8u/nYyCPEY0B8NCAByJnQWVzA== X-Received: by 2002:a05:6820:1613:b0:659:9a49:8ea2 with SMTP id 006d021491bc7-65f54f5e7f8mr8630491eaf.38.1768230172463; Mon, 12 Jan 2026 07:02:52 -0800 (PST) Received: from newman.cs.purdue.edu ([128.10.127.250]) by smtp.gmail.com with ESMTPSA id 006d021491bc7-65f48ab2d00sm7311748eaf.0.2026.01.12.07.02.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 12 Jan 2026 07:02:51 -0800 (PST) From: Jiasheng Jiang To: jiashengjiangcool@gmail.com Cc: clm@fb.com, dsterba@suse.com, fdmanana@kernel.org, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH v3] btrfs: reset block group size class when reservations are freed Date: Mon, 12 Jan 2026 15:02:48 +0000 Message-Id: <20260112150248.32570-1-jiashengjiangcool@gmail.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20260112143523.31542-1-jiashengjiangcool@gmail.com> References: <20260112143523.31542-1-jiashengjiangcool@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Differential analysis of block-group.c shows an inconsistency between btrfs_add_reserved_bytes() and btrfs_free_reserved_bytes(). When space is reserved, btrfs_use_block_group_size_class() is called to set a block group's size class, specializing it for a specific allocation size to reduce fragmentation. However, when these reservations are subsequently freed (e.g., due to an error or transaction abort), btrfs_free_reserved_bytes() fails to perform the corresponding cleanup. This leads to a state where a block group remains stuck with a specific size class even if it contains no used or reserved bytes. While the impact depends on the workload, this stale state can cause find_free_extent to unnecessarily skip these block groups for mismatched size requests. In some cases, it may even trigger the allocation of new block groups if no matching or unassigned block groups are available. Fix this by resetting the size class to BTRFS_BG_SZ_NONE in btrfs_free_reserved_bytes() when the block group becomes completely empty. Fixes: 52bb7a2166af ("btrfs: introduce size class to block group allocator") Signed-off-by: Jiasheng Jiang --- Changelog: v2 -> v3: 1. Corrected the "Fixes" tag to 52bb7a2166af. 2. Updated the commit message to reflect that the performance impact is wor= kload-dependent. 3. Added mention that the issue can lead to unnecessary allocation of new b= lock groups. v1 -> v2: 1. Inlined btrfs_maybe_reset_size_class() function. 2. Moved check below the reserved bytes decrement in btrfs_free_reserved_by= tes(). --- fs/btrfs/block-group.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/fs/btrfs/block-group.c b/fs/btrfs/block-group.c index 08b14449fabe..8339ad001d3f 100644 --- a/fs/btrfs/block-group.c +++ b/fs/btrfs/block-group.c @@ -3867,6 +3867,12 @@ void btrfs_free_reserved_bytes(struct btrfs_block_gr= oup *cache, u64 num_bytes, spin_lock(&cache->lock); bg_ro =3D cache->ro; cache->reserved -=3D num_bytes; + + if (btrfs_block_group_should_use_size_class(cache)) { + if (cache->used =3D=3D 0 && cache->reserved =3D=3D 0) + cache->size_class =3D BTRFS_BG_SZ_NONE; + } + if (is_delalloc) cache->delalloc_bytes -=3D num_bytes; spin_unlock(&cache->lock); --=20 2.25.1