Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp335199imm; Thu, 12 Jul 2018 20:59:26 -0700 (PDT) X-Google-Smtp-Source: AAOMgpeHQzmUDCDCJR2DrP+738BHedjkfB357J9uJ6FohZrWuIAVRFHKJwrAY+Cfooek1SG+375e X-Received: by 2002:a62:5f82:: with SMTP id t124-v6mr3176774pfb.223.1531454366395; Thu, 12 Jul 2018 20:59:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1531454366; cv=none; d=google.com; s=arc-20160816; b=ruOTuTxCWBJiaLmBUaF5fE/u9MA++s2PNBiyxf1B+qkWXlbR81mV6v4eDYEGggD2y2 Ygs/CtVvP1uUG1g6WnouCtlrbv6vL0/HogkhKL1KxtJFuZUn5DbhIhPVTrwywTbFc3el 2uXRP+fQ2bvz09XqA1Y5F4M7nIPvkzyaX4xZtrflrRjPWNM0X7T06RWBTA6g+0gORWjN 28URXLchfpROWL+tJr9IyrunKrcu8ikJgE4zAU+rjF8A+0tZXLHQlB86H3AYmBv0cCXx 7AkzRgSA6RNIFc2wJQS28yMFpETFURIs/0kGZoiEs6vr2NFi+waVq0t1HofE4m6VmSKi nOGg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-language :content-transfer-encoding:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=zCpnSMpEs3VWL7vNNaa+lFIclBuJw7oV2iO8+iRyUr4=; b=YNMwgwQKPzHxSJZIIvknYB4ZzWepaA7MoblB9JjK9gA5NXHxqBckC4DYRcAG9Vvtp6 EMZeavUgUmRcE/w/BcdmnDI7q51fQij3xCy2/SZGNC6lymHtW3sQns9M7ACm+p4QeS2h zUsnEsGukhA3nNAnAhAZbhRsBKOR/trTUGUGzA52iSiTiBjaODyRyGXanl3YZ4MD8x/r lWrOashv0dMoesIG63aTv5x9kGepUotJMZxZeYEtnYR5llri17Rs1nuiswFD/ia4zSRH Wsgj5AgvCaxNP3oITn8z2t424Xsx//OI+PPV0vd7d63oTXwMOy0hvDqDJpdB9/otcPUM SDRA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id n8-v6si22755308pgl.101.2018.07.12.20.59.11; Thu, 12 Jul 2018 20:59:26 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726088AbeGMELS (ORCPT + 99 others); Fri, 13 Jul 2018 00:11:18 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:9232 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725862AbeGMELS (ORCPT ); Fri, 13 Jul 2018 00:11:18 -0400 Received: from DGGEMS403-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 6A8D2E737E0B6; Fri, 13 Jul 2018 11:52:38 +0800 (CST) Received: from [127.0.0.1] (10.111.220.140) by DGGEMS403-HUB.china.huawei.com (10.3.19.203) with Microsoft SMTP Server id 14.3.382.0; Fri, 13 Jul 2018 11:52:32 +0800 Subject: Re: [PATCH 2/5] f2fs: clear the remaining prefree_map of the section To: Chao Yu , , , CC: , , , , , References: <1531408170-45758-1-git-send-email-yunlong.song@huawei.com> <1531408170-45758-3-git-send-email-yunlong.song@huawei.com> <75dc9cad-8166-82c5-e085-88c9623f5c5e@huawei.com> <12f3c3d2-6586-ca73-8770-8f97b436d643@huawei.com> From: Yunlong Song Message-ID: <52acc420-2a08-c5e9-f63e-74d63fb11126@huawei.com> Date: Fri, 13 Jul 2018 11:51:59 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <12f3c3d2-6586-ca73-8770-8f97b436d643@huawei.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Originating-IP: [10.111.220.140] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Because in f2fs_clear_prefree_segments, the codes: ... while (1) { int i; start = find_next_bit(prefree_map, MAIN_SEGS(sbi), end + 1); if (start >= MAIN_SEGS(sbi)) break; end = find_next_zero_bit(prefree_map, MAIN_SEGS(sbi), start + 1); for (i = start; i < end; i++) clear_bit(i, prefree_map); ... next: secno = GET_SEC_FROM_SEG(sbi, start); start_segno = GET_SEG_FROM_SEC(sbi, secno); if (!IS_CURSEC(sbi, secno) && !get_valid_blocks(sbi, start, true)) f2fs_issue_discard(sbi, START_BLOCK(sbi, start_segno), sbi->segs_per_sec << sbi->log_blocks_per_seg); start = start_segno + sbi->segs_per_sec; if (start < end) goto next; else end = start - 1; ... In round 2, for prefree_map: 1 1 0 1 1, start = 0, end = 2, then start = start_segno + sbi->segs_per_sec makes start = 5 if (start < end) --> start = 5, end = 2 so end = start -1 --> end = 4, then return to while again, this time skips prefree bit 3 and 4. On 2018/7/13 11:42, Chao Yu wrote: > On 2018/7/13 11:28, Yunlong Song wrote: >> round 1: section bitmap : 1 1 1 1 1, all valid, prefree_map: 0 0 0 0 0 >> then rm data block NO.2, block NO.2 becomes invalid, prefree_map: 0 0 1 0 0 >> write_checkpoint: section bitmap: 1 1 0 1 1, prefree_map: 0 0 0 0 0, >> prefree of NO.2 is cleared, and no discard issued >> >> round2: rm data block NO.0, NO.1, NO.3, NO.4 >> all invalid, but prefree bit of NO.2 is set and cleared in round1, then >> prefree_map: 1 1 0 1 1 >> write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1, no > Why prefree_map is not 0 0 0 0 0? > > Thanks, > >> valid blocks of this section, so discard issued >> but this time prefree bit of NO.3 and NO.4 is skipped... >> >> round3: >> write_checkpoint: section bitmap: 0 0 0 0 0, prefree_map: 0 0 0 1 1 - > >> 0 0 0 0 0, no valid blocks of this section, so discard issued >> this time prefree bit of NO.3 and NO.4 is cleared, but the discard of >> this section is sent again... >> >> On 2018/7/13 11:13, Chao Yu wrote: >>> On 2018/7/12 23:09, Yunlong Song wrote: >>>> For the case when sbi->segs_per_sec > 1, take section:segment = 5 for >>>> example, if the section prefree_map is ...previous section | current >>>> section (1 1 0 1 1) | next section..., then the start = x, end = x + 1, >>>> after start = start_segno + sbi->segs_per_sec, start = x + 5, then it >>>> will skip x + 3 and x + 4, but their bitmap is still set, which will >>>> cause duplicated f2fs_issue_discard of this same section in the next >>>> write_checkpoint, so fix it. >>> I didn't get it, if # 2 segment is not prefree state, so it still has valid >>> blocks there, so we won't issue discard due to below condition, right? >>> >>> if (!IS_CURSEC(sbi, secno) && >>> !get_valid_blocks(sbi, start, true)) >>> >>> Thanks, >>> >>>> Signed-off-by: Yunlong Song >>>> --- >>>> fs/f2fs/segment.c | 19 +++++++++++++++++-- >>>> 1 file changed, 17 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c >>>> index 47b6595..fd38b61 100644 >>>> --- a/fs/f2fs/segment.c >>>> +++ b/fs/f2fs/segment.c >>>> @@ -1684,8 +1684,23 @@ void f2fs_clear_prefree_segments(struct f2fs_sb_info *sbi, >>>> start = start_segno + sbi->segs_per_sec; >>>> if (start < end) >>>> goto next; >>>> - else >>>> - end = start - 1; >>>> + else { >>>> + start_segno = start; >>>> + >>>> + while (1) { >>>> + start = find_next_bit(prefree_map, start_segno, >>>> + end + 1); >>>> + if (start >= start_segno) >>>> + break; >>>> + end = find_next_zero_bit(prefree_map, start_segno, >>>> + start + 1); >>>> + for (i = start; i < end; i++) >>>> + clear_bit(i, prefree_map); >>>> + dirty_i->nr_dirty[PRE] -= end - start; >>>> + } >>>> + >>>> + end = start_segno - 1; >>>> + } >>>> } >>>> mutex_unlock(&dirty_i->seglist_lock); >>>> >>>> >>> . >>> > > . > -- Thanks, Yunlong Song