[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <397db70a-8592-2a7a-1b77-303925491bf2@linux.ibm.com>
Date: Wed, 16 Sep 2020 15:46:02 +0530
From: Ritesh Harjani <riteshh@...ux.ibm.com>
To: Ye Bin <yebin10@...wei.com>
Cc: Jan Kara <jack@...e.cz>, tytso@....edu, adilger.kernel@...ger.ca,
jack@...e.com, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v4] ext4: Fix dead loop in ext4_mb_new_blocks
On 9/15/20 5:41 PM, Jan Kara wrote:
> On Mon 14-09-20 18:47:42, Ye Bin wrote:
>> As we test disk offline/online with running fsstress, we find fsstress
>> process is keeping running state.
>> kworker/u32:3-262 [004] ...1 140.787471: ext4_mb_discard_preallocations: dev 8,32 needed 114
>> ....
>> kworker/u32:3-262 [004] ...1 140.787471: ext4_mb_discard_preallocations: dev 8,32 needed 114
>>
>> ext4_mb_new_blocks
>> repeat:
>> ext4_mb_discard_preallocations_should_retry(sb, ac, &seq)
>> freed = ext4_mb_discard_preallocations
>> ext4_mb_discard_group_preallocations
>> this_cpu_inc(discard_pa_seq);
>> ---> freed == 0
>> seq_retry = ext4_get_discard_pa_seq_sum
>> for_each_possible_cpu(__cpu)
>> __seq += per_cpu(discard_pa_seq, __cpu);
>> if (seq_retry != *seq) {
>> *seq = seq_retry;
>> ret = true;
>> }
>>
>> As we see seq_retry is sum of discard_pa_seq every cpu, if
>> ext4_mb_discard_group_preallocations return zero discard_pa_seq in this
>> cpu maybe increase one, so condition "seq_retry != *seq" have always
>> been met.
>> Ritesh Harjani suggest to in ext4_mb_discard_group_preallocations function we
>> only increase discard_pa_seq when there is some PA to free.
@yebin,
Did you confirm by running your test case that this patch indeed fixes
your reported issue.
With that confirmed, the patch does looks good to me. Feel free to add.
Reviewed-by: Ritesh Harjani <riteshh@...ux.ibm.com>
>>
>> Fixes: 07b5b8e1ac40 ("ext4: mballoc: introduce pcpu seqcnt for freeing PA to improve ENOSPC handling")
>> Signed-off-by: Ye Bin <yebin10@...wei.com>
>
> The patch looks good to me. You can add:
>
> Reviewed-by: Jan Kara <jack@...e.cz>
>
> But as I mentioned in my previous reply I also think the attached patch
> also needs to be merged to avoid premature ENOSPC errors (which your change
> makes somewhat more likely). Ritesh do you agree?
Yes, agree that Jan's attached patch should help to avoid premature
ENOSPC errors. We should have his patch too on top of current patch.
@yebin
Should we have a v5 of then, with both patches included for merging?
Powered by blists - more mailing lists