From: Jaegeuk Kim <jaegeuk@kernel.org> To: Chao Yu <chao@kernel.org> Cc: Yufen Yu <yuyufen@huawei.com>, 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: Mon, 11 Apr 2022 14:20:41 -0700 [thread overview] Message-ID: <YlSbqay8y6oaCxR6@google.com> (raw) In-Reply-To: <778b1f04-a71b-a226-f7a7-4833fc9bf7c2@kernel.org> 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. BTW, what is the real benefit to use the fault injection 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: Jaegeuk Kim <jaegeuk@kernel.org> To: Chao Yu <chao@kernel.org> Cc: linux-f2fs-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org Subject: Re: [f2fs-dev] [PATCH 4/5] f2fs: get rid of stale fault injection code Date: Mon, 11 Apr 2022 14:20:41 -0700 [thread overview] Message-ID: <YlSbqay8y6oaCxR6@google.com> (raw) In-Reply-To: <778b1f04-a71b-a226-f7a7-4833fc9bf7c2@kernel.org> 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. BTW, what is the real benefit to use the fault injection 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-11 21:21 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 [this message] 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 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=YlSbqay8y6oaCxR6@google.com \ --to=jaegeuk@kernel.org \ --cc=chao@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.