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
next prev parent 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: linkBe 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.