All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
To: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>,
	linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 3/3] btrfs: increase output size for LOGICAL_INO_V2 ioctl
Date: Sat, 23 Sep 2017 23:06:42 +0200	[thread overview]
Message-ID: <c2778a9a-3d94-7888-657c-317c5bbf1ed7@mendix.com> (raw)
In-Reply-To: <20170922175847.6071-4-ce3g8jdj@umail.furryterror.org>

On 09/22/2017 07:58 PM, Zygo Blaxell wrote:
> Build-server workloads have hundreds of references per file after dedup.
> Multiply by a few snapshots and we quickly exhaust the limit of 2730
> references per extent that can fit into a 64K buffer.

Simulating this scenario:

/btrfs 2-# btrfs sub create 0
Create subvolume './0'
/btrfs 2-# cp /boot/vmlinuz-4.14.0-rc1-zygo1 0/0
/btrfs 2-# for i in $(seq 1 499); do cp --reflink 0/0 0/$i; done
/btrfs 2-# for i in $(seq 1 5); do btrfs sub snap 0 $i; done
Create a snapshot of '0' in './1'
Create a snapshot of '0' in './2'
Create a snapshot of '0' in './3'
Create a snapshot of '0' in './4'
Create a snapshot of '0' in './5'

-# ./show_block_groups.py /btrfs
block group vaddr 0 length 4194304 flags SYSTEM used 16384 used_pct 0
block group vaddr 4194304 length 8388608 flags METADATA used 507904
used_pct 6
block group vaddr 12582912 length 8388608 flags DATA used 4198400
used_pct 50
block group vaddr 20971520 length 268435456 flags METADATA used 0 used_pct 0

-# ./show_block_group_contents.py 12582912 /btrfs
block group vaddr 12582912 length 8388608 flags DATA used 4198400
used_pct 50
extent vaddr 12582912 length 4198400 refs 500 gen 25 flags DATA
    inline extent data backref root 257 objectid 262 offset 0 count 1
    inline extent data backref root 257 objectid 277 offset 0 count 1
    inline extent data backref root 257 objectid 288 offset 0 count 1
    [...]
    extent data backref root 257 objectid 663 offset 0 count 1
    extent data backref root 257 objectid 366 offset 0 count 1
    extent data backref root 257 objectid 715 offset 0 count 1
    extent data backref root 257 objectid 306 offset 0 count 1
    extent data backref root 257 objectid 470 offset 0 count 1
    [...]

Total 500 lines, the extra 2500 files in the snapshots are hidden behind
the shared metadata refs now...

> 
> Raise the limit to 16M to be consistent with other btrfs ioctls
> (e.g. TREE_SEARCH_V2, FILE_EXTENT_SAME).
> 
> To minimize surprising userspace behavior, apply this change only to
> the LOGICAL_INO_V2 ioctl.
> 
> Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org>
> ---
>  fs/btrfs/ioctl.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
> index f4281ffd1833..1940678fc440 100644
> --- a/fs/btrfs/ioctl.c
> +++ b/fs/btrfs/ioctl.c
> @@ -4554,6 +4554,7 @@ static long btrfs_ioctl_logical_to_ino(struct btrfs_fs_info *fs_info,
>  
>  	if (version == 1) {
>  		ignore_offset = false;
> +		size = min_t(u32, loi->size, SZ_64K);
>  	} else {
>  		/* All reserved bits must be 0 for now */
>  		if (memchr_inv(loi->reserved, 0, sizeof(loi->reserved))) {
> @@ -4566,6 +4567,7 @@ static long btrfs_ioctl_logical_to_ino(struct btrfs_fs_info *fs_info,
>  			goto out_loi;
>  		}
>  		ignore_offset = loi->flags & BTRFS_LOGICAL_INO_ARGS_IGNORE_OFFSET;
> +		size = min_t(u32, loi->size, SZ_16M);
>  	}
>  
>  	path = btrfs_alloc_path();
> @@ -4574,7 +4576,6 @@ static long btrfs_ioctl_logical_to_ino(struct btrfs_fs_info *fs_info,
>  		goto out;
>  	}
>  
> -	size = min_t(u32, loi->size, SZ_64K);
>  	inodes = init_data_container(size);
>  	if (IS_ERR(inodes)) {
>  		ret = PTR_ERR(inodes);
> 

>>> import btrfs
>>> fs = btrfs.FileSystem('/btrfs')

Checking that 'v1' still works:

>>> inodes, bytes_missed = btrfs.ioctl.logical_to_ino(fs.fd, 12582912,
65536)
>>> len(inodes)
2730
>>> bytes_missed
6480

Yes, we only get 2730, as expected with a 64k buffer.

v2 can do the same:

>>> inodes, bytes_missed = btrfs.ioctl.logical_to_ino_v2(fs.fd,
12582912, 65536)
>>> len(inodes)
2730
>>> bytes_missed
6480

The bytes_missed is really useful, because it tells us the exact size of
the buf we need instead :)

>>> inodes, bytes_missed = btrfs.ioctl.logical_to_ino_v2(fs.fd,
12582912, 65536 + 6480)
>>> len(inodes)
3000
>>> bytes_missed
0

Yay!

If I remove the buffer size sanity check inside the python-btrfs ioctl code:

>>> import btrfs
>>> fs = btrfs.FileSystem('/btrfs')
>>> inodes, bytes_missed = btrfs.ioctl.logical_to_ino(fs.fd, 12582912,
65536 + 6480)
>>> len(inodes)
2730
>>> bytes_missed
6480

Yes, buffer still gets truncated to 64k in the v1 code.

Reviewed-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com>
Tested-by: Hans van Kranenburg <hans.van.kranenburg@mendix.com>

-- 
Hans van Kranenburg

  reply	other threads:[~2017-09-23 21:06 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-22 17:58 [PATCH v3] btrfs: LOGICAL_INO enhancements Zygo Blaxell
2017-09-22 17:58 ` [PATCH 1/3] btrfs: add a flag to iterate_inodes_from_logical to find all extent refs for uncompressed extents Zygo Blaxell
2017-10-19 17:03   ` David Sterba
2017-09-22 17:58 ` [PATCH 2/3] btrfs: add a flags argument to LOGICAL_INO and call it LOGICAL_INO_V2 Zygo Blaxell
2017-09-23 20:38   ` Hans van Kranenburg
2017-09-22 17:58 ` [PATCH 3/3] btrfs: increase output size for LOGICAL_INO_V2 ioctl Zygo Blaxell
2017-09-23 21:06   ` Hans van Kranenburg [this message]
2017-10-19 17:07     ` David Sterba
2019-08-30  7:55 ` Fwd: [PATCH v3] btrfs: LOGICAL_INO enhancements Anand Jain
  -- strict thread matches above, loose matches on Subject: below --
2017-09-21  4:10 [PATCH v2] btrfs: LOGICAL_INO enhancements (this time based on 4.14-rc1) Zygo Blaxell
2017-09-21  4:10 ` [PATCH 3/3] btrfs: increase output size for LOGICAL_INO_V2 ioctl Zygo Blaxell
2017-09-21  0:33 [PATCH 1/3] btrfs: add a flag to iterate_inodes_from_logical to find all extent refs for uncompressed extents Zygo Blaxell
2017-09-21  0:33 ` [PATCH 3/3] btrfs: increase output size for LOGICAL_INO_V2 ioctl Zygo Blaxell

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=c2778a9a-3d94-7888-657c-317c5bbf1ed7@mendix.com \
    --to=hans.van.kranenburg@mendix.com \
    --cc=ce3g8jdj@umail.furryterror.org \
    --cc=linux-btrfs@vger.kernel.org \
    /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.