Re: [PATCH 0/2] btrfs: cleanup related to the 1MiB reserved space

From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <wqu@suse.com>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 0/2] btrfs: cleanup related to the 1MiB reserved space
Date: Mon, 13 Jun 2022 20:20:34 +0200	[thread overview]
Message-ID: <20220613182034.GC20633@twin.jikos.cz> (raw)
In-Reply-To: <cover.1655103954.git.wqu@suse.com>

On Mon, Jun 13, 2022 at 03:06:33PM +0800, Qu Wenruo wrote:
> The 1MiB reserved space is only introduced in v4.1 btrfs-progs, and
> kernel has the same reserved space around the same time.

Kernel had this since the beginnning, or do you have pointer for the
commits? I know that progs wrongly allocated some of the tree roots
under 1M and this got fixed, but otherwise kernel never used the 1st
megabyte for allocations.

> But there are two small nitpicks:
> 
> - Kernel never has a unified MACRO for this
>   We just use SZ_1M, with extra comments on this.
> 
>   This makes later write-intent bitmap harder to implement, as the
>   incoming write-intent bitmap will enlarge the reserved space to
>   2MiB, and use the extra 1MiB for write-intent bitmap.
>   (of course with extra RO compat flags)
> 
>   This will be addressed in the first patch, with a new
>   BTRFS_DEFAULT_RESERVED macro.

Cleaning up the raw 1M value and the comments makes sense, but I'm not
sure about making it dynamic. We used to have mount option and mkfs
parameter alloc_offset and it got removed.

>   Later write-intent bitmap code will use BTRFS_DEFAULT_RESERVED as a
>   beacon to ensure btrfs never touches the enlarged reserved space.

Ok, I'll wait with further comments until I see the patches.