We don't need to wait for whole bunch of discard candidates in fstrim, since
runtime discard will issue them in idle time.

Signed-off-by: Jaegeuk Kim <jaeg...@kernel.org>
---
 fs/f2fs/segment.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index bef74d628f66..b1e58b10425f 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -2439,9 +2439,18 @@ int f2fs_trim_fs(struct f2fs_sb_info *sbi, struct 
fstrim_range *range)
 
        __init_discard_policy(sbi, &dpolicy, DPOLICY_FSTRIM, cpc.trim_minlen);
        __issue_discard_cmd_range(sbi, &dpolicy, start_block, end_block);
-       trimmed = __wait_discard_cmd_range(sbi, &dpolicy,
+
+       /*
+        * We filed discard candidates, but actually we don't need to wait for
+        * all of them, since they'll be issued in idle time along with runtime
+        * discard option. User configuration looks like using runtime discard
+        * or periodic fstrim instead of it.
+        */
+       if (!test_opt(sbi, DISCARD)) {
+               trimmed = __wait_discard_cmd_range(sbi, &dpolicy,
                                        start_block, end_block);
-       range->len = F2FS_BLK_TO_BYTES(trimmed);
+               range->len = F2FS_BLK_TO_BYTES(trimmed);
+       }
 out:
        return err;
 }
-- 
2.17.0.441.gb46fe60e1d-goog


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Reply via email to