On 2018/4/13 6:37, Jaegeuk Kim wrote: > On 04/10, Yunlei He wrote: >> In flush_sit_entries::add_discard_addrs path, cur_map and ckpt_map >> are the same, but in exist_trim_candidates::add_discard_addrs, >> cur_map is updated one, and newer than ckpt_map, so we need to use >> cur_map to check whether there are discard candidates. >> >> v1->v2: one problem of check discard candidates reported by Chao, >> besides, update commit message. >> >> Signed-off-by: Yunlei He <heyun...@huawei.com> >> --- >> fs/f2fs/segment.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c >> index 5854cc4..f5d0499 100644 >> --- a/fs/f2fs/segment.c >> +++ b/fs/f2fs/segment.c >> @@ -1559,7 +1559,7 @@ static bool add_discard_addrs(struct f2fs_sb_info >> *sbi, struct cp_control *cpc, >> >> /* SIT_VBLOCK_MAP_SIZE should be multiple of sizeof(unsigned long) */ >> for (i = 0; i < entries; i++) >> - dmap[i] = force ? ~ckpt_map[i] & ~discard_map[i] : >> + dmap[i] = force ? ~cur_map[i] & ~discard_map[i] : > > NAK. We're able to loose data for roll-forward recovery.
Actually, in fstrim flow (force == 1), cur_map is complete the same as ckpt_map. Do you suffer data corruption during testing this patch? Thanks, > >> (cur_map[i] ^ ckpt_map[i]) & ckpt_map[i]; >> >> while (force || SM_I(sbi)->dcc_info->nr_discards <= >> -- >> 1.9.1 > > . > ------------------------------------------------------------------------------ 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
