On 2023/11/15 10:45, Jaegeuk Kim wrote:
> On 11/15, Chao Yu wrote:
>> On 2023/11/15 5:24, Jaegeuk Kim wrote:
>>> When recovering zoned UFS, sometimes we add the same zone to discard multiple
>>> times. Simple workaround is to bypass adding it.
>>
>> What about skipping f2fs_bug_on() just for zoned UFS case? so that the check
>> condition can still be used for non-zoned UFS case.
>
> Hmm, I've never seen this bug_on before, but even this really happens, it does
I've never seen it was been triggered as well.
> not make sense to move forward to create duplicate commands resulting in a loop.
Agreed.
It looks those codes were copied from extent_cache code base, do we need to fix
all cases to avoid loop?
>
> So, the question is, do we really need to check this? Have we hit this before?
Not sure, just be worry about that flaw of newly developed feature can make
code run into that branch.
Thanks,
>
>>
>> Thanks,
>>
>>>
>>> Signed-off-by: Jaegeuk Kim <[email protected]>
>>> ---
>>> fs/f2fs/segment.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>> index 727d016318f9..f4ffd64b44b2 100644
>>> --- a/fs/f2fs/segment.c
>>> +++ b/fs/f2fs/segment.c
>>> @@ -1380,7 +1380,8 @@ static void __insert_discard_cmd(struct f2fs_sb_info *sbi,
>>> p = &(*p)->rb_right;
>>> leftmost = false;
>>> } else {
>>> - f2fs_bug_on(sbi, 1);
>>> + /* Let's skip to add, if exists */
>>> + return;
>>> }
>>> }
On 11/15, Chao Yu wrote:
> On 2023/11/15 10:45, Jaegeuk Kim wrote:
> > On 11/15, Chao Yu wrote:
> > > On 2023/11/15 5:24, Jaegeuk Kim wrote:
> > > > When recovering zoned UFS, sometimes we add the same zone to discard multiple
> > > > times. Simple workaround is to bypass adding it.
> > >
> > > What about skipping f2fs_bug_on() just for zoned UFS case? so that the check
> > > condition can still be used for non-zoned UFS case.
> >
> > Hmm, I've never seen this bug_on before, but even this really happens, it does
>
> I've never seen it was been triggered as well.
>
> > not make sense to move forward to create duplicate commands resulting in a loop.
>
> Agreed.
>
> It looks those codes were copied from extent_cache code base, do we need to fix
> all cases to avoid loop?
Not sure other cases yet.. let's do one by one, since I hit this in real.
>
> >
> > So, the question is, do we really need to check this? Have we hit this before?
> Not sure, just be worry about that flaw of newly developed feature can make
> code run into that branch.
>
> Thanks,
>
> >
> > >
> > > Thanks,
> > >
> > > >
> > > > Signed-off-by: Jaegeuk Kim <[email protected]>
> > > > ---
> > > > fs/f2fs/segment.c | 3 ++-
> > > > 1 file changed, 2 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > > > index 727d016318f9..f4ffd64b44b2 100644
> > > > --- a/fs/f2fs/segment.c
> > > > +++ b/fs/f2fs/segment.c
> > > > @@ -1380,7 +1380,8 @@ static void __insert_discard_cmd(struct f2fs_sb_info *sbi,
> > > > p = &(*p)->rb_right;
> > > > leftmost = false;
> > > > } else {
> > > > - f2fs_bug_on(sbi, 1);
> > > > + /* Let's skip to add, if exists */
> > > > + return;
> > > > }
> > > > }
On 2023/11/18 1:41, Jaegeuk Kim wrote:
> Not sure other cases yet.. let's do one by one, since I hit this in real.
Sure.
>>>>> Signed-off-by: Jaegeuk Kim <[email protected]>
Reviewed-by: Chao Yu <[email protected]>
Thansk,