From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from submarine.notk.org (submarine.notk.org [62.210.214.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 07D0F2FB997 for ; Tue, 3 Feb 2026 07:07:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=62.210.214.84 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770102430; cv=none; b=GmJPe95uEqlcQf8CGlKOP28F4ZBxcskZntVGW5yrK1d7qpC0qtwVpvd/q8ufJVyFt5UDeDRI/+D+En7gSTAGTQbLsO9hQrpx6BnY99VNa03E5LTua/NWxTFa7XQK/AUMHVf5hVEKEw3QecymNQNhwnjtLEH0eqS3hga81PgNhdM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770102430; c=relaxed/simple; bh=+8onjeqxbUNpqLiR3U7Lpe3EOip5nv/XShMw5Yo6yQA=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=X3dJC3JvlGY3arAibGV4Fgy3juvb2eE5UVxuew1/rf6mzeLWGqN6mFmAcs6VOJlbKVSZeZ9pdFRCN0mhY/MCOcKYnnfL3RCMr2pTW6xHLnXXAt0O+PqvPIGxAgmHUzFjS7Mp04F5LE19xjY71XXyZF1oh3xF8+f1i8fgNFZuAHw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org; spf=pass smtp.mailfrom=codewreck.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b=eWV9Ze1l; arc=none smtp.client-ip=62.210.214.84 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=codewreck.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=codewreck.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=codewreck.org header.i=@codewreck.org header.b="eWV9Ze1l" Received: from gaia.codewreck.org (localhost [127.0.0.1]) by submarine.notk.org (Postfix) with ESMTPS id D5B9D14C2D6; Tue, 3 Feb 2026 08:06:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=codewreck.org; s=2; t=1770102420; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OkU/P7xKqr3jhYD8+CzMsDsQQ4nZwwzsOY5rQK9+kDM=; b=eWV9Ze1lLsi/+l7BDJFgz8WaxFkXaT7zPOn80dqSwcCq5Ck8RklI4PH8/6wbdt5YO9xADm I6gxkfa0uRh3pKeXut+s7Aer6d1AFEOe+gHrh5VrlXWLMvjMubtLR52QHa2qxXQePVx0so pesbmkNHWlS4CFyNkjkAhtwlJ8FvhdaeNUIKrgJu21savsQP4Dz6sxt5qwjEUWWrlbl5J9 0ZqZD8i0SF5HrD5Lecn95aVLG9Kp9qQAHW/qZpsCfMAsUvMYM+QVulSoiqYVg7lrTfTTNy Wg6lizNsopd/O5eqse3USrX52EG/jIUTSZ9cesRZWVmf+Bej7cSK1vaLO/gu3A== Received: from localhost (gaia.codewreck.org [local]) by gaia.codewreck.org (OpenSMTPD) with ESMTPA id f7d6d662; Tue, 3 Feb 2026 07:06:57 +0000 (UTC) Date: Tue, 3 Feb 2026 16:06:42 +0900 From: Dominique Martinet To: Qu Wenruo Cc: Christoph Anton Mitterer , Qu Wenruo , linux-btrfs Subject: Re: We have a space info key for a block group that doesn't exist Message-ID: References: <31615495f428dbe499ae5f5a109cc6c74c8979ca.camel@scientia.org> Precedence: bulk X-Mailing-List: linux-btrfs@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Hi Qu, Qu Wenruo wrote on Wed, Nov 19, 2025 at 09:59:55AM +1030: >>> We have a space info key for a block group that doesn't exist >> >> So even without clearing the cache as you've proposed below, it >> couldn't have caused any post or future corruption, right?! > > Yep. Allocation is always happening based on a block group, such > orphan space info/bitmap keys won't cause the allocator to use it > anyway. > > So no corruption or whatever. We're running rountine btrfsck before copying the filesystem for cloning in one of our tools, and I'm starting to get user reports of errors due to this error (we run an ancient 5.10 kernel but there hadn't been any such report, and now we just got two in a couple of weeks so something must have been backported to the stable tree...) Anyway, I agree with your answer that it's safe to ignore, but it's not obvious for users to decide that, so I'd like to address this somehow. If it's really harmless, could it be printed as info message but not change the btrfsck return code? (e.g. if that's the only error, return success) If you think it's worth keeping as an error, would you (or someone else) happen to have any idea where I should start looking? (Alternatively since we're not copying at the block level I guess there's no real need for this check in the first place, as any real corruption would cause IO error, and I could just forget about this... The check was just ported e2fsck from back when the fs was ext4...) Thanks, -- Dominique Martinet | Asmadeus