fs/f2fs/segment.c | 6 ++++-- fs/f2fs/super.c | 8 ++------ 2 files changed, 6 insertions(+), 8 deletions(-)
No need to call f2fs_issue_discard_timeout() in f2fs_put_super,
when no discard command requires issue. Since the caller of
f2fs_issue_discard_timeout() usually judges the number of discard
commands before using it. Let's move this logic to
f2fs_issue_discard_timeout().
By the way, use f2fs_realtime_discard_enable to simplify the code.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Yangtao Li <frank.li@vivo.com>
---
fs/f2fs/segment.c | 6 ++++--
fs/f2fs/super.c | 8 ++------
2 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index 9486ca49ecb1..d5f150a08285 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -1655,6 +1655,9 @@ bool f2fs_issue_discard_timeout(struct f2fs_sb_info *sbi)
struct discard_policy dpolicy;
bool dropped;
+ if (!atomic_read(&dcc->discard_cmd_cnt))
+ return false;
+
__init_discard_policy(sbi, &dpolicy, DPOLICY_UMOUNT,
dcc->discard_granularity);
__issue_discard_cmd(sbi, &dpolicy);
@@ -2110,8 +2113,7 @@ static void destroy_discard_cmd_control(struct f2fs_sb_info *sbi)
* Recovery can cache discard commands, so in error path of
* fill_super(), it needs to give a chance to handle them.
*/
- if (unlikely(atomic_read(&dcc->discard_cmd_cnt)))
- f2fs_issue_discard_timeout(sbi);
+ f2fs_issue_discard_timeout(sbi);
kfree(dcc);
SM_I(sbi)->dcc_info = NULL;
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index 79bf1faf4161..aa1cadfd34a5 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1576,8 +1576,7 @@ static void f2fs_put_super(struct super_block *sb)
/* be sure to wait for any on-going discard commands */
dropped = f2fs_issue_discard_timeout(sbi);
- if ((f2fs_hw_support_discard(sbi) || f2fs_hw_should_discard(sbi)) &&
- !sbi->discard_blks && !dropped) {
+ if (f2fs_realtime_discard_enable(sbi) && !sbi->discard_blks && !dropped) {
struct cp_control cpc = {
.reason = CP_UMOUNT | CP_TRIMMED,
};
@@ -2225,7 +2224,6 @@ static int f2fs_remount(struct super_block *sb, int *flags, char *data)
bool no_discard = !test_opt(sbi, DISCARD);
bool no_compress_cache = !test_opt(sbi, COMPRESS_CACHE);
bool block_unit_discard = f2fs_block_unit_discard(sbi);
- struct discard_cmd_control *dcc;
#ifdef CONFIG_QUOTA
int i, j;
#endif
@@ -2406,10 +2404,8 @@ static int f2fs_remount(struct super_block *sb, int *flags, char *data)
goto restore_flush;
need_stop_discard = true;
} else {
- dcc = SM_I(sbi)->dcc_info;
f2fs_stop_discard_thread(sbi);
- if (atomic_read(&dcc->discard_cmd_cnt))
- f2fs_issue_discard_timeout(sbi);
+ f2fs_issue_discard_timeout(sbi);
need_restart_discard = true;
}
}
--
2.25.1On 2022/12/2 12:58, Yangtao Li wrote:
> No need to call f2fs_issue_discard_timeout() in f2fs_put_super,
> when no discard command requires issue. Since the caller of
> f2fs_issue_discard_timeout() usually judges the number of discard
> commands before using it. Let's move this logic to
> f2fs_issue_discard_timeout().
>
> By the way, use f2fs_realtime_discard_enable to simplify the code.
>
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Yangtao Li <frank.li@vivo.com>
> ---
> fs/f2fs/segment.c | 6 ++++--
> fs/f2fs/super.c | 8 ++------
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 9486ca49ecb1..d5f150a08285 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1655,6 +1655,9 @@ bool f2fs_issue_discard_timeout(struct f2fs_sb_info *sbi)
> struct discard_policy dpolicy;
> bool dropped;
>
> + if (!atomic_read(&dcc->discard_cmd_cnt))
> + return false;
> +
> __init_discard_policy(sbi, &dpolicy, DPOLICY_UMOUNT,
> dcc->discard_granularity);
> __issue_discard_cmd(sbi, &dpolicy);
> @@ -2110,8 +2113,7 @@ static void destroy_discard_cmd_control(struct f2fs_sb_info *sbi)
> * Recovery can cache discard commands, so in error path of
> * fill_super(), it needs to give a chance to handle them.
> */
> - if (unlikely(atomic_read(&dcc->discard_cmd_cnt)))
> - f2fs_issue_discard_timeout(sbi);
> + f2fs_issue_discard_timeout(sbi);
>
> kfree(dcc);
> SM_I(sbi)->dcc_info = NULL;
> diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
> index 79bf1faf4161..aa1cadfd34a5 100644
> --- a/fs/f2fs/super.c
> +++ b/fs/f2fs/super.c
> @@ -1576,8 +1576,7 @@ static void f2fs_put_super(struct super_block *sb)
> /* be sure to wait for any on-going discard commands */
> dropped = f2fs_issue_discard_timeout(sbi);
>
> - if ((f2fs_hw_support_discard(sbi) || f2fs_hw_should_discard(sbi)) &&
> - !sbi->discard_blks && !dropped) {
> + if (f2fs_realtime_discard_enable(sbi) && !sbi->discard_blks && !dropped) {
static inline bool f2fs_realtime_discard_enable(struct f2fs_sb_info *sbi)
{
return (test_opt(sbi, DISCARD) && f2fs_hw_support_discard(sbi)) ||
f2fs_hw_should_discard(sbi);
}
It looks the logic is changed?
Thanks,
> struct cp_control cpc = {
> .reason = CP_UMOUNT | CP_TRIMMED,
> };
> @@ -2225,7 +2224,6 @@ static int f2fs_remount(struct super_block *sb, int *flags, char *data)
> bool no_discard = !test_opt(sbi, DISCARD);
> bool no_compress_cache = !test_opt(sbi, COMPRESS_CACHE);
> bool block_unit_discard = f2fs_block_unit_discard(sbi);
> - struct discard_cmd_control *dcc;
> #ifdef CONFIG_QUOTA
> int i, j;
> #endif
> @@ -2406,10 +2404,8 @@ static int f2fs_remount(struct super_block *sb, int *flags, char *data)
> goto restore_flush;
> need_stop_discard = true;
> } else {
> - dcc = SM_I(sbi)->dcc_info;
> f2fs_stop_discard_thread(sbi);
> - if (atomic_read(&dcc->discard_cmd_cnt))
> - f2fs_issue_discard_timeout(sbi);
> + f2fs_issue_discard_timeout(sbi);
> need_restart_discard = true;
> }
> }
Hi,
> static inline bool f2fs_realtime_discard_enable(struct f2fs_sb_info *sbi) {
> return (test_opt(sbi, DISCARD) && f2fs_hw_support_discard(sbi)) ||
> f2fs_hw_should_discard(sbi);
> }
> It looks the logic is changed?
For a storage device that does not support discard, and we have not actually
issued any discard command. I don't think it is necessary and f2fs should not
be equipped with trim markers.
Thx,
Yangtao
On 2022/12/12 21:05, Yangtao Li wrote:
> Hi,
>
>> static inline bool f2fs_realtime_discard_enable(struct f2fs_sb_info *sbi) {
>> return (test_opt(sbi, DISCARD) && f2fs_hw_support_discard(sbi)) ||
>> f2fs_hw_should_discard(sbi);
>> }
>
>> It looks the logic is changed?
>
> For a storage device that does not support discard, and we have not actually
> issued any discard command. I don't think it is necessary and f2fs should not
> be equipped with trim markers.
The difference here is, if we use f2fs_realtime_discard_enable() in
f2fs_put_super(), we will only write checkpoint w/ CP_TRIMMED flag
when discard option is enable and device supports discard.
But actually, if discard option is disabled, we still needs to give
put_super() a chance to write checkpoint w/ CP_TRIMMED flag.
Thanks,
>
> Thx,
> Yangtao
Hi Chao, > The difference here is, if we use f2fs_realtime_discard_enable() in > f2fs_put_super(), we will only write checkpoint w/ CP_TRIMMED flag > when discard option is enable and device supports discard. > But actually, if discard option is disabled, we still needs to give > put_super() a chance to write checkpoint w/ CP_TRIMMED flag. Why do we still have to set the CP_TRIMMED flag when the discard opt is not set. Did I miss something? Thx, Yangtao
On 2022/12/12 22:14, Yangtao Li wrote: > Hi Chao, > >> The difference here is, if we use f2fs_realtime_discard_enable() in >> f2fs_put_super(), we will only write checkpoint w/ CP_TRIMMED flag >> when discard option is enable and device supports discard. > >> But actually, if discard option is disabled, we still needs to give >> put_super() a chance to write checkpoint w/ CP_TRIMMED flag. > > Why do we still have to set the CP_TRIMMED flag when the discard opt is not set. > Did I miss something? Hi Yangtao, I guess it's up to scenario. e.g. mount w/ nodiscard and use FITRIM to trigger in-batch discard, if we set CP_TRIMMED flag during umount, next time, after mount w/ discard, it doesn't to issue redundant discard. Thanks, > > Thx, > Yangtao
On 12/12, Chao Yu wrote: > On 2022/12/12 22:14, Yangtao Li wrote: > > Hi Chao, > > > > > The difference here is, if we use f2fs_realtime_discard_enable() in > > > f2fs_put_super(), we will only write checkpoint w/ CP_TRIMMED flag > > > when discard option is enable and device supports discard. > > > > > But actually, if discard option is disabled, we still needs to give > > > put_super() a chance to write checkpoint w/ CP_TRIMMED flag. > > > > Why do we still have to set the CP_TRIMMED flag when the discard opt is not set. > > Did I miss something? > > Hi Yangtao, > > I guess it's up to scenario. e.g. > > mount w/ nodiscard and use FITRIM to trigger in-batch discard, > if we set CP_TRIMMED flag during umount, next time, after mount > w/ discard, it doesn't to issue redundant discard. If fitrim was called with a range, we can get a wrong FI_TRIMMED flag. Isn't it better to get a full discard range after remount even though some are redundant? > > Thanks, > > > > > Thx, > > Yangtao
On 2022/12/13 6:45, Jaegeuk Kim wrote:
> On 12/12, Chao Yu wrote:
>> On 2022/12/12 22:14, Yangtao Li wrote:
>>> Hi Chao,
>>>
>>>> The difference here is, if we use f2fs_realtime_discard_enable() in
>>>> f2fs_put_super(), we will only write checkpoint w/ CP_TRIMMED flag
>>>> when discard option is enable and device supports discard.
>>>
>>>> But actually, if discard option is disabled, we still needs to give
>>>> put_super() a chance to write checkpoint w/ CP_TRIMMED flag.
>>>
>>> Why do we still have to set the CP_TRIMMED flag when the discard opt is not set.
>>> Did I miss something?
>>
>> Hi Yangtao,
>>
>> I guess it's up to scenario. e.g.
>>
>> mount w/ nodiscard and use FITRIM to trigger in-batch discard,
>> if we set CP_TRIMMED flag during umount, next time, after mount
>> w/ discard, it doesn't to issue redundant discard.
>
> If fitrim was called with a range, we can get a wrong FI_TRIMMED flag. Isn't it
We can set CP_TRIMMED flag only if fitrim was called on full range w/ 4k granularity,
due to it will check sbi->discard_blks variable to make sure there is no range we
haven't trimmed.
> better to get a full discard range after remount even though some are redundant?
If nodiscard is set, and sbi->discard_blks becomes zero, it says a full range fitrim
was been triggered.
So, previous check condition has no problem, right?
if ((f2fs_hw_support_discard(sbi) || f2fs_hw_should_discard(sbi)) &&
!sbi->discard_blks && !dropped) {
Thanks,
>
>>
>> Thanks,
>>
>>>
>>> Thx,
>>> Yangtao
On 12/13, Chao Yu wrote:
> On 2022/12/13 6:45, Jaegeuk Kim wrote:
> > On 12/12, Chao Yu wrote:
> > > On 2022/12/12 22:14, Yangtao Li wrote:
> > > > Hi Chao,
> > > >
> > > > > The difference here is, if we use f2fs_realtime_discard_enable() in
> > > > > f2fs_put_super(), we will only write checkpoint w/ CP_TRIMMED flag
> > > > > when discard option is enable and device supports discard.
> > > >
> > > > > But actually, if discard option is disabled, we still needs to give
> > > > > put_super() a chance to write checkpoint w/ CP_TRIMMED flag.
> > > >
> > > > Why do we still have to set the CP_TRIMMED flag when the discard opt is not set.
> > > > Did I miss something?
> > >
> > > Hi Yangtao,
> > >
> > > I guess it's up to scenario. e.g.
> > >
> > > mount w/ nodiscard and use FITRIM to trigger in-batch discard,
> > > if we set CP_TRIMMED flag during umount, next time, after mount
> > > w/ discard, it doesn't to issue redundant discard.
> >
> > If fitrim was called with a range, we can get a wrong FI_TRIMMED flag. Isn't it
>
> We can set CP_TRIMMED flag only if fitrim was called on full range w/ 4k granularity,
> due to it will check sbi->discard_blks variable to make sure there is no range we
> haven't trimmed.
>
> > better to get a full discard range after remount even though some are redundant?
>
> If nodiscard is set, and sbi->discard_blks becomes zero, it says a full range fitrim
> was been triggered.
That gives another assumption, and I prefer to make it simple.
>
> So, previous check condition has no problem, right?
>
> if ((f2fs_hw_support_discard(sbi) || f2fs_hw_should_discard(sbi)) &&
> !sbi->discard_blks && !dropped) {
>
> Thanks,
>
> >
> > >
> > > Thanks,
> > >
> > > >
> > > > Thx,
> > > > Yangtao
© 2016 - 2025 Red Hat, Inc.