All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: Anand Jain <anand.jain@oracle.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: allow defrag to convert inline extents to regular extents
Date: Mon, 9 May 2022 10:17:55 +0800	[thread overview]
Message-ID: <a9cc3342-9658-5f5c-c26b-80a3c7bc9ee8@suse.com> (raw)
In-Reply-To: <981a54b2-884e-0426-22e7-f8a332d7b331@oracle.com>



On 2022/5/9 10:15, Anand Jain wrote:
> On 5/7/22 12:09, Qu Wenruo wrote:
>> Btrfs defaults to max_inline=2K to make small writes inlined into
>> metadata.
>>
>> The default value is always a win, as even DUP/RAID1/RAID10 doubles the
>> metadata usage, it should still cause less physical space used compared
>> to a 4K regular extents.
>>
>> But since the introduce of RAID1C3 and RAID1C4 it's no longer the case,
>> users may find inlined extents causing too much space wasted, and want
>> to convert those inlined extents back to regular extents.
>>
>> Unfortunately defrag will unconditionally skip all inline extents, no
>> matter if the user is trying to converting them back to regular extents.
>>
>> So this patch will add a small exception for defrag_collect_targets() to
>> allow defragging inline extents, if and only if the inlined extents are
>> larger than max_inline, allowing users to convert them to regular ones.
>>
>> Signed-off-by: Qu Wenruo <wqu@suse.com>
>> ---
>>   fs/btrfs/ioctl.c | 24 ++++++++++++++++++++++--
>>   1 file changed, 22 insertions(+), 2 deletions(-)
>>
>> diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
>> index 9d8e46815ee4..852c49565ab2 100644
>> --- a/fs/btrfs/ioctl.c
>> +++ b/fs/btrfs/ioctl.c
>> @@ -1420,8 +1420,19 @@ static int defrag_collect_targets(struct 
>> btrfs_inode *inode,
>>           if (!em)
>>               break;
>> -        /* Skip hole/inline/preallocated extents */
>> -        if (em->block_start >= EXTENT_MAP_LAST_BYTE ||
>> +        /*
>> +         * If the file extent is an inlined one, we may still want to
>> +         * defrag it (fallthrough) if it will cause a regular extent.
>> +         * This is for users who want to convert inline extents to
>> +         * regular ones through max_inline= mount option.
>> +         */
>> +        if (em->block_start == EXTENT_MAP_INLINE &&
>> +            em->len <= inode->root->fs_info->max_inline)
>> +            goto next;
>> +
>> +        /* Skip hole/delalloc/preallocated extents */
>> +        if (em->block_start == EXTENT_MAP_HOLE ||
>> +            em->block_start == EXTENT_MAP_DELALLOC ||
>>               test_bit(EXTENT_FLAG_PREALLOC, &em->flags))
>>               goto next;
>> @@ -1480,6 +1491,15 @@ static int defrag_collect_targets(struct 
>> btrfs_inode *inode,
>>           if (em->len >= get_extent_max_capacity(em))
>>               goto next;
> 
> 
>> +        /*
>> +         * For inline extent it should be the first extent and it
>> +         * should not have a next extent.
>> +         * If the inlined extent passed all above checks, just add it
>> +         * for defrag, and be converted to regular extents.
>> +         */
>> +        if (em->block_start == EXTENT_MAP_INLINE)
>> +            goto add;
>> +
>>           next_mergeable = defrag_check_next_extent(&inode->vfs_inode, 
>> em,
>>                           extent_thresh, newer_than, locked);
>>           if (!next_mergeable) {
> Why not also let the inline extent have the next_mergeable checked?
> So the new regular extent will defrag. No?

You definitely forget the fact that inline extent should NOT have 
regular extents following it.

> 
> -Anand
> 


  reply	other threads:[~2022-05-09  2:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-07  6:39 [PATCH] btrfs: allow defrag to convert inline extents to regular extents Qu Wenruo
2022-05-09  2:15 ` Anand Jain
2022-05-09  2:17   ` Qu Wenruo [this message]
2022-05-09  2:22     ` Anand Jain
2022-05-09  9:56 ` Filipe Manana
2022-05-09 11:12   ` Qu Wenruo
2022-05-09 11:29     ` Filipe Manana

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=a9cc3342-9658-5f5c-c26b-80a3c7bc9ee8@suse.com \
    --to=wqu@suse.com \
    --cc=anand.jain@oracle.com \
    --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.