Re: [PATCH 1/5] btrfs: 1G falloc extents

[Qu Wenruo <quwenruo.btrfs@gmx.com>]

On 2022/10/6 03:49, Boris Burkov wrote:
> When doing a large fallocate, btrfs will break it up into 256MiB
> extents. Our data block groups are 1GiB, so a more natural maximum size
> is 1GiB, so that we tend to allocate and fully use block groups rather
> than fragmenting the file around.
>
> This is especially useful if large fallocates tend to be for "round"
> amounts, which strikes me as a reasonable assumption.
>
> While moving to size classes reduces the value of this change, it is
> also good to compare potential allocator algorithms against just 1G
> extents.

Btrfs extent booking is already causing a lot of wasted space, is this
larger extent size really a good idea?

E.g. after a lot of random writes, we may have only a very small part of
the original 1G still being referred.
(The first write into the pre-allocated range will not be COWed, but the
next one over the same range will be COWed)

But the full 1G can only be freed if none of its sectors is referred.
Thus this would make preallocated space much harder to be free,
snapshots/reflink can make it even worse.

So wouldn't such enlarged preallocted extent size cause more pressure?

In fact, the original 256M is already too large to me.

Thanks,
Qu
>
> Signed-off-by: Boris Burkov <boris@bur.io>
> ---
>   fs/btrfs/inode.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
> index 45ebef8d3ea8..fd66586ae2fc 100644
> --- a/fs/btrfs/inode.c
> +++ b/fs/btrfs/inode.c
> @@ -9884,7 +9884,7 @@ static int __btrfs_prealloc_file_range(struct inode *inode, int mode,
>   	if (trans)
>   		own_trans = false;
>   	while (num_bytes > 0) {
> -		cur_bytes = min_t(u64, num_bytes, SZ_256M);
> +		cur_bytes = min_t(u64, num_bytes, SZ_1G);
>   		cur_bytes = max(cur_bytes, min_size);
>   		/*
>   		 * If we are severely fragmented we could end up with really