mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Heming Zhao <heming.zhao@suse.com>
To: Joseph Qi <joseph.qi@linux.alibaba.com>, glass.su@suse.com
Cc: ocfs2-devel@lists.linux.dev,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 1/3] ocfs2: give ocfs2 the ability to reclaim suballoc free bg
Date: Tue, 3 Sep 2024 08:43:16 +0800	[thread overview]
Message-ID: <19557432-ce04-4a92-9a3c-83539ab73648@suse.com> (raw)
In-Reply-To: <88c9e6fd-db43-4c58-81f1-caa38369e732@linux.alibaba.com>

On 9/2/24 19:25, Joseph Qi wrote:
> 
> 
> On 7/29/24 4:04 PM, Heming Zhao wrote:
>> The current ocfs2 code can't reclaim suballocator block group space.
>> This cause ocfs2 to hold onto a lot of space in some cases. for example,
>> when creating lots of small files, the space is held/managed by
>> '//inode_alloc'. After the user deletes all the small files, the space
>> never returns to '//global_bitmap'. This issue prevents ocfs2 from
>> providing the needed space even when there is enough free space in a
>> small ocfs2 volume.
>> This patch gives ocfs2 the ability to reclaim suballoc free space when
>> the block group is free. For performance reasons, ocfs2 doesn't release
>> the first suballocator block group.
>>
>> Signed-off-by: Heming Zhao <heming.zhao@suse.com>
>> ---
>>   fs/ocfs2/suballoc.c | 211 ++++++++++++++++++++++++++++++++++++++++++--
>>   1 file changed, 206 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/ocfs2/suballoc.c b/fs/ocfs2/suballoc.c
>> index f7b483f0de2a..1b64f4c87607 100644
>> --- a/fs/ocfs2/suballoc.c
>> +++ b/fs/ocfs2/suballoc.c
>> @@ -294,6 +294,60 @@ static int ocfs2_validate_group_descriptor(struct super_block *sb,
>>   	return ocfs2_validate_gd_self(sb, bh, 0);
>>   }
>>   
>> +/*
>> + * hint gd may already be released in _ocfs2_free_suballoc_bits(),
>> ... ...
>> +	alloc_bh = main_bm_bh;
>> +	fe = (struct ocfs2_dinode *) alloc_bh->b_data;
>> +	cl = &fe->id2.i_chain;
>> +	old_bg_contig_free_bits = 0;
>> +	brelse(group_bh);
>> +	group_bh = NULL;
>> +	start_bit = bg_start_bit;
>> +	undo_fn = _ocfs2_clear_bit;
>> +
>> +	/* reclaim clusters to global_bitmap */
>> +	goto reclaim;
>> +
>>   bail:
>> +	if (free_main_bm_bh) {
>> +		ocfs2_inode_unlock(main_bm_inode, 1);
>> +		brelse(main_bm_bh);
>> +	}
>> +	if (free_main_bm_inode) {
>> +		inode_unlock(main_bm_inode);
>> +		iput(main_bm_inode);
>> +	}
> 
> You've add too much logic into _ocfs2_free_suballoc_bits() and make it
> hard to review.
> Could you please factor out a new function and describe it clearly?
> e.g. why we need this function and how to achieve it.
> BTW, it seems that it contains a big loop, so please explictly specify
> the end condition.
> 
> Cc lkml as well.
> 
> Thanks,
> Joseph

Give me some time to do the factor out job.

- Heming

> 
>>   	brelse(group_bh);
>>   	return status;
>>   }
> 
> 


  reply	other threads:[~2024-09-03  0:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240729080454.12771-1-heming.zhao@suse.com>
     [not found] ` <20240729080454.12771-2-heming.zhao@suse.com>
2024-09-02 11:25   ` Joseph Qi
2024-09-03  0:43     ` Heming Zhao [this message]
     [not found] ` <20240729080454.12771-3-heming.zhao@suse.com>
2024-09-02 11:43   ` [PATCH v2 2/3] ocfs2: detect released suballocator bg for fh_to_[dentry|parent] Joseph Qi

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=19557432-ce04-4a92-9a3c-83539ab73648@suse.com \
    --to=heming.zhao@suse.com \
    --cc=glass.su@suse.com \
    --cc=joseph.qi@linux.alibaba.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ocfs2-devel@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®