All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Yufen Yu <yuyufen@huawei.com>, Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 4/5] f2fs: get rid of stale fault injection code
Date: Tue, 19 Apr 2022 10:56:18 +0800	[thread overview]
Message-ID: <752a79ff-aaf5-d2a8-02a7-1ec63ca954e0@kernel.org> (raw)
In-Reply-To: <7c6a3d09-0215-cb7d-cf82-0c4fd801d998@huawei.com>

On 2022/4/12 19:04, Yufen Yu via Linux-f2fs-devel wrote:
> 
> 
> On 2022/4/12 5:20, Jaegeuk Kim wrote:
>> On 04/11, Chao Yu wrote:
>>> On 2022/4/6 11:01, Yufen Yu via Linux-f2fs-devel wrote:
>>>> Hi,
>>>>
>>>> On 2022/4/1 16:28, Chao Yu wrote:
>>>>> On 2022/4/1 15:19, Yufen Yu via Linux-f2fs-devel wrote:
>>>>>> Nowly, we can use new fault injection framework. Just delete the
>>>>>> stale fault injection code.
>>>>>>
>>>>>> Signed-off-by: Yufen Yu <yuyufen@huawei.com>
>>>>>> ---
>>>>>>    fs/f2fs/checkpoint.c |  2 +-
>>>>>>    fs/f2fs/f2fs.h       | 51 ++----------------------------------------
>>>>>>    fs/f2fs/super.c      | 53 --------------------------------------------
>>>>>>    fs/f2fs/sysfs.c      | 23 -------------------
>>>>>>    4 files changed, 3 insertions(+), 126 deletions(-)
>>>>>>
>>>>
>>>> ...
>>>>
>>>>>>                break;
>>>>>> @@ -1963,14 +1920,6 @@ static int f2fs_show_options(struct seq_file *seq, struct dentry *root)
>>>>>>        if (F2FS_IO_SIZE_BITS(sbi))
>>>>>>            seq_printf(seq, ",io_bits=%u",
>>>>>>                    F2FS_OPTION(sbi).write_io_size_bits);
>>>>>> -#ifdef CONFIG_F2FS_FAULT_INJECTION
>>>>>> -    if (test_opt(sbi, FAULT_INJECTION)) {
>>>>>> -        seq_printf(seq, ",fault_injection=%u",
>>>>>> -                F2FS_OPTION(sbi).fault_info.inject_rate);
>>>>>> -        seq_printf(seq, ",fault_type=%u",
>>>>>> -                F2FS_OPTION(sbi).fault_info.inject_type);
>>>>>> -    }
>>>>>> -#endif
>>>>>
>>>>> This will cause regression due to it breaks application usage w/ -o
>>>>> fault_* mountoption..., I don't think this is the right way.
>>>>
>>>>
>>>> Thanks for catching this. I admit it's a problem. But, IMO fault_* mount
>>>> option are mostly been used in test, not in actual product. So, I think
>>>> it may just affect some test applications. With the common fault injection
>>>> framework, it can be more easy and flexible to do fault injection test.
>>>> Therefore, I want to remove the two mount options directly.
>>>>
>>>> If you really worried about compatibility, how about just reserving the
>>>> two inject_* options but without doing any thing for them. We actually
>>>> configure fault injections by debugfs in this patch.
>>>>
>>>> Or do you have more better suggestion?
>>>
>>> Could you please consider to keep original logic of f2fs fault injection
>>> if user use inject_* options, otherwise following common fault injection
>>> framework?
>>>
>>> Thoughts?
>>
>> I think it'd be useful to test roll-forward recovery flow by using those mount
>> options, since runtime fault injection cannot enable it during mount.
>>
> 
> Yeah, I have not catch this point before.
> 
>> BTW, what is the real benefit to use the fault injection framework?
>>
> 
> I think fault injection framework can provide more easier and flexible
> function than the current one. Furthermore, we can just following it and
> don't need to maintain f2fs own fault injection cold.

Yufen,

As Jaegeuk mentioned, it needs to keep original f2fs fault injection
framework code in order to cover test during mount(). IIUC.

IMO, one way to add this framework is making those two framework
compatible, but before that, could you please explain the details
of benefit for adapting the common framework?

Thanks,

> 
> Thanks,
> Yufen
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

WARNING: multiple messages have this Message-ID (diff)
From: Chao Yu <chao@kernel.org>
To: Yufen Yu <yuyufen@huawei.com>, Jaegeuk Kim <jaegeuk@kernel.org>
Cc: linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net
Subject: Re: [f2fs-dev] [PATCH 4/5] f2fs: get rid of stale fault injection code
Date: Tue, 19 Apr 2022 10:56:18 +0800	[thread overview]
Message-ID: <752a79ff-aaf5-d2a8-02a7-1ec63ca954e0@kernel.org> (raw)
In-Reply-To: <7c6a3d09-0215-cb7d-cf82-0c4fd801d998@huawei.com>

On 2022/4/12 19:04, Yufen Yu via Linux-f2fs-devel wrote:
> 
> 
> On 2022/4/12 5:20, Jaegeuk Kim wrote:
>> On 04/11, Chao Yu wrote:
>>> On 2022/4/6 11:01, Yufen Yu via Linux-f2fs-devel wrote:
>>>> Hi,
>>>>
>>>> On 2022/4/1 16:28, Chao Yu wrote:
>>>>> On 2022/4/1 15:19, Yufen Yu via Linux-f2fs-devel wrote:
>>>>>> Nowly, we can use new fault injection framework. Just delete the
>>>>>> stale fault injection code.
>>>>>>
>>>>>> Signed-off-by: Yufen Yu <yuyufen@huawei.com>
>>>>>> ---
>>>>>>    fs/f2fs/checkpoint.c |  2 +-
>>>>>>    fs/f2fs/f2fs.h       | 51 ++----------------------------------------
>>>>>>    fs/f2fs/super.c      | 53 --------------------------------------------
>>>>>>    fs/f2fs/sysfs.c      | 23 -------------------
>>>>>>    4 files changed, 3 insertions(+), 126 deletions(-)
>>>>>>
>>>>
>>>> ...
>>>>
>>>>>>                break;
>>>>>> @@ -1963,14 +1920,6 @@ static int f2fs_show_options(struct seq_file *seq, struct dentry *root)
>>>>>>        if (F2FS_IO_SIZE_BITS(sbi))
>>>>>>            seq_printf(seq, ",io_bits=%u",
>>>>>>                    F2FS_OPTION(sbi).write_io_size_bits);
>>>>>> -#ifdef CONFIG_F2FS_FAULT_INJECTION
>>>>>> -    if (test_opt(sbi, FAULT_INJECTION)) {
>>>>>> -        seq_printf(seq, ",fault_injection=%u",
>>>>>> -                F2FS_OPTION(sbi).fault_info.inject_rate);
>>>>>> -        seq_printf(seq, ",fault_type=%u",
>>>>>> -                F2FS_OPTION(sbi).fault_info.inject_type);
>>>>>> -    }
>>>>>> -#endif
>>>>>
>>>>> This will cause regression due to it breaks application usage w/ -o
>>>>> fault_* mountoption..., I don't think this is the right way.
>>>>
>>>>
>>>> Thanks for catching this. I admit it's a problem. But, IMO fault_* mount
>>>> option are mostly been used in test, not in actual product. So, I think
>>>> it may just affect some test applications. With the common fault injection
>>>> framework, it can be more easy and flexible to do fault injection test.
>>>> Therefore, I want to remove the two mount options directly.
>>>>
>>>> If you really worried about compatibility, how about just reserving the
>>>> two inject_* options but without doing any thing for them. We actually
>>>> configure fault injections by debugfs in this patch.
>>>>
>>>> Or do you have more better suggestion?
>>>
>>> Could you please consider to keep original logic of f2fs fault injection
>>> if user use inject_* options, otherwise following common fault injection
>>> framework?
>>>
>>> Thoughts?
>>
>> I think it'd be useful to test roll-forward recovery flow by using those mount
>> options, since runtime fault injection cannot enable it during mount.
>>
> 
> Yeah, I have not catch this point before.
> 
>> BTW, what is the real benefit to use the fault injection framework?
>>
> 
> I think fault injection framework can provide more easier and flexible
> function than the current one. Furthermore, we can just following it and
> don't need to maintain f2fs own fault injection cold.

Yufen,

As Jaegeuk mentioned, it needs to keep original f2fs fault injection
framework code in order to cover test during mount(). IIUC.

IMO, one way to add this framework is making those two framework
compatible, but before that, could you please explain the details
of benefit for adapting the common framework?

Thanks,

> 
> Thanks,
> Yufen
> 
> 
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel


_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

  reply	other threads:[~2022-04-19  2:56 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-04-01  7:19 [PATCH 0/5] f2fs: try to use common fault injection framework Yufen Yu
2022-04-01  7:19 ` [f2fs-dev] " Yufen Yu via Linux-f2fs-devel
2022-04-01  7:19 ` [PATCH 1/5] f2fs: extract f2fs root debugfs to init_f2fs_fs Yufen Yu
2022-04-01  7:19   ` [f2fs-dev] " Yufen Yu via Linux-f2fs-devel
2022-04-01  7:19 ` [PATCH 2/5] f2fs: use common fault injection frmework Yufen Yu
2022-04-01  7:19   ` [f2fs-dev] " Yufen Yu via Linux-f2fs-devel
2022-04-01  7:19 ` [PATCH 3/5] f2fs: replace function time_to_inject by f2fs_should_fail Yufen Yu
2022-04-01  7:19   ` [f2fs-dev] " Yufen Yu via Linux-f2fs-devel
2022-04-01  7:19 ` [PATCH 4/5] f2fs: get rid of stale fault injection code Yufen Yu
2022-04-01  7:19   ` [f2fs-dev] " Yufen Yu via Linux-f2fs-devel
2022-04-01  8:28   ` Chao Yu
2022-04-01  8:28     ` Chao Yu
2022-04-06  3:01     ` Yufen Yu via Linux-f2fs-devel
2022-04-06  3:01       ` Yufen Yu
2022-04-11 10:04       ` Chao Yu
2022-04-11 10:04         ` Chao Yu
2022-04-11 21:20         ` Jaegeuk Kim
2022-04-11 21:20           ` Jaegeuk Kim
2022-04-12 11:04           ` Yufen Yu via Linux-f2fs-devel
2022-04-12 11:04             ` Yufen Yu
2022-04-19  2:56             ` Chao Yu [this message]
2022-04-19  2:56               ` Chao Yu
2022-04-01  7:19 ` [PATCH 5/5] f2fs: update doc for f2fs fault injection Yufen Yu
2022-04-01  7:19   ` [f2fs-dev] " Yufen Yu via Linux-f2fs-devel

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=752a79ff-aaf5-d2a8-02a7-1ec63ca954e0@kernel.org \
    --to=chao@kernel.org \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=yuyufen@huawei.com \
    /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.