All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wang Yugui <wangyugui@e16-tech.com>
To: Boris Burkov <boris@bur.io>
Cc: linux-btrfs@vger.kernel.org, kernel-team@fb.com,
	Qu Wenruo <quwenruo.btrfs@gmx.com>,
	Filipe Manana <fdmanana@kernel.org>
Subject: Re: [PATCH 1/5] btrfs: 1G falloc extents
Date: Fri, 07 Oct 2022 11:23:07 +0800	[thread overview]
Message-ID: <20221007112306.F62D.409509F4@e16-tech.com> (raw)
In-Reply-To: <cace4a8be466b9c4fee288c768c5384988c1fca8.1664999303.git.boris@bur.io>

Hi,

> 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.


I wrote a 32G file, and the compare the result of 'xfs_io -c fiemap'.

dd conv=fsync bs=1024K count=32K if=/dev/zero of=/mnt/test/dd.txt

When write to a btrfs filesystem
+ xfs_io -c fiemap /mnt/test/dd.txt
/mnt/test/dd.txt:
        0: [0..262143]: 6883584..7145727
        1: [262144..524287]: 6367232..6629375
        2: [524288..8126463]: 7145728..14747903
        3: [8126464..8388607]: 15272064..15534207
        4: [8388608..8650751]: 14755840..15017983
        5: [8650752..16252927]: 15534208..23136383
        6: [16252928..67108863]: 23144448..74000383

When write to a xfs filesystem
+ xfs_io -c fiemap /mnt/test/dd.txt
/mnt/test/dd.txt:
        0: [0..16465919]: 256..16466175
        1: [16465920..31821623]: 16466176..31821879
        2: [31821624..41942903]: 31821880..41943159
        3: [41942904..58720111]: 47183872..63961079
        4: [58720112..67108863]: 63961080..72349831

the max of xfs is about 8G, but the max of btrfs is 
about 25G('6: [16252928..67108863]'?

Best Regards
Wang Yugui (wangyugui@e16-tech.com)
2022/10/07



> 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
> -- 
> 2.37.2



  parent reply	other threads:[~2022-10-07  3:23 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-05 19:49 [PATCH 0/5] btrfs: data block group size classes Boris Burkov
2022-10-05 19:49 ` [PATCH 1/5] btrfs: 1G falloc extents Boris Burkov
2022-10-06  7:37   ` Qu Wenruo
2022-10-06  9:48     ` Filipe Manana
2022-10-06 18:38       ` Boris Burkov
2022-10-06 19:56         ` Filipe Manana
2022-10-06 20:41           ` Boris Burkov
2022-10-06 23:03             ` Qu Wenruo
2022-10-06  8:48   ` Johannes Thumshirn
2022-10-07  3:23   ` Wang Yugui [this message]
2022-10-07  3:29     ` Qu Wenruo
2022-10-07  3:40       ` Qu Wenruo
2022-10-05 19:49 ` [PATCH 2/5] btrfs: use ffe_ctl in btrfs allocator tracepoints Boris Burkov
2022-10-11 13:03   ` David Sterba
2022-10-14 12:22     ` David Sterba
2022-10-05 19:49 ` [PATCH 3/5] btrfs: add more ffe tracepoints Boris Burkov
2022-10-05 19:49 ` [PATCH 4/5] btrfs: introduce size class to block group allocator Boris Burkov
2022-10-05 19:49 ` [PATCH 5/5] btrfs: load block group size class when caching Boris Burkov
2022-10-06  6:02   ` kernel test robot
2022-10-06  7:31   ` kernel test robot
2022-10-06  8:13   ` kernel test robot
2022-10-11 13:06 ` [PATCH 0/5] btrfs: data block group size classes David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20221007112306.F62D.409509F4@e16-tech.com \
    --to=wangyugui@e16-tech.com \
    --cc=boris@bur.io \
    --cc=fdmanana@kernel.org \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=quwenruo.btrfs@gmx.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.