Received: by 2002:a05:6a10:a841:0:0:0:0 with SMTP id d1csp1014772pxy; Thu, 22 Apr 2021 20:37:55 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwz7eh7r8N8hJ+VDoRNjTP6gBHj3el1UbPaUPPBg2KgFMJCTDe5eVoVpQ8NBwPA8OPFRuEh X-Received: by 2002:aa7:8e0d:0:b029:214:a511:d88b with SMTP id c13-20020aa78e0d0000b0290214a511d88bmr2022670pfr.2.1619149075271; Thu, 22 Apr 2021 20:37:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1619149075; cv=none; d=google.com; s=arc-20160816; b=oee57Q4X0zJEg6YRRlJPqFYBks2Cs31YyYU7EPgV31cicBaEd2dv60Xd0T89cXgTaF 6LvSFSRNRHZGzGI3BkjhsPV52ZOlHSnP6FBwNKO3e5yitINFUksaz+7yN7oR8wVIhXJi V0DLs3QlxXV3BoVcVw/1Oa8/N7yRaJYLFTBCv0LylAPCOOqBHwblpQMrsywN3BrKjbWB eSux0YBDnd52bxGyoxkCbfDMs4hV69k/AKyxczt4zXO3WNuAgEfTvw2Wzxp/eErYvzla EXcDSUHNd1U/ZtH8jxBSP7ZsyppZAh8AAT0qtvYwlRofZQ6DF0CX1zEiPgI6Jpl7k+2i 276A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject; bh=4HDTHeJYOQ2B9kiO9zkD3HiEKONChlcFD2IKZHQHVjc=; b=Xv+8g7WJwLLuBkPfg/zDlSCSlB7Zi7uxa04wHwlCosKErQIve/8tu0VJf0G81qYNc7 7meGzXRLMhRMW/DlvcyZ7wzno2GQjfxqJdJD5jJXQSfXUD1WhbcNqddQPAwpWnvMfC38 s4VrN012yxMy7uK55mCZ1R4cO0jjgV/lf3/obJA1yEIt7vCtBV4YDgY4RdX1Hte00iRD i44/p6luzIOaQxZicG6wiKD2zYYKyJ8G0zM/6nmAadfjf8/r3HbWJo+awBn3DtuBn8ST /k7iMYmss6iimYtBGkxNnR1/uVfV1cnmFi3NTvXRasF57RySKyZajx51qhf8Ror8Rqpr R9Ww== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c26si6476175pfj.280.2021.04.22.20.37.42; Thu, 22 Apr 2021 20:37:55 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240195AbhDWDhs (ORCPT + 99 others); Thu, 22 Apr 2021 23:37:48 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:16152 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231261AbhDWDhr (ORCPT ); Thu, 22 Apr 2021 23:37:47 -0400 Received: from DGGEMS405-HUB.china.huawei.com (unknown [172.30.72.58]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FRKdq6wF0zpbFn; Fri, 23 Apr 2021 11:34:07 +0800 (CST) Received: from [10.136.110.154] (10.136.110.154) by smtp.huawei.com (10.3.19.205) with Microsoft SMTP Server (TLS) id 14.3.498.0; Fri, 23 Apr 2021 11:37:06 +0800 Subject: Re: [f2fs-dev] [PATCH] f2fs: set prefree as free segments after clear prefree segments To: =?UTF-8?B?5p2O5oms6Z+s?= CC: , , , References: From: Chao Yu Message-ID: <3323e5c0-cd52-528a-6a57-5982db05a4bf@huawei.com> Date: Fri, 23 Apr 2021 11:37:05 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [10.136.110.154] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yangtao, On 2021/4/23 10:40, 李扬韬 wrote: > HI Chao, > >>> For now, when do_checkpoint fails, the prefree bitmap is not cleared, >>> but these segments are already in the free state. If these segments >>> are used, the segments in use will be reset to the free state when >>> f2fs_clear_prefree_segments is called next time. >>> >>> So move set_prefree_as_free_segments after clear_prefree_segments. >> >> That's not correct. >> >> /* >> * Should call f2fs_clear_prefree_segments after checkpoint is done. >> */ >> static void set_prefree_as_free_segments(struct f2fs_sb_info *sbi) >> >> Comments above set_prefree_as_free_segments() should have told you >> the rule, otherwise if checkpoint failed, valid data in last valid >> checkpoint could be corrupted after segment reuse. Oh, it seems I misunderstood what the patch did, please ignore above comments. > > For do_checkpoint sucess: > > f2fs_write_checkpoint > ->f2fs_flush_sit_entries > ->set_prefree_as_free_segments > ->do_checkpoint > ->f2fs_clear_prefree_segments > > > Calling set_prefree_as_free_segments when do_checkpoint fails, > seems to be incorrect. I think clear free bitmap should be after > clear prefree bitmap. > > For do_checkpoint fail: > > f2fs_write_checkpoint > ->f2fs_flush_sit_entries > ->set_prefree_as_free_segments > ->do_checkpoint > ->f2fs_release_discard_addrs > > The prefree bitmap is not cleared, but free bitmap is cleared,which means > we can use these segments that are marked as free. When the free segments > is used, the next f2fs_clear_prefree_segments will mark prefree as free again, > causing some problem. Okay, I can understand that. But the problem here is, after applying this patch, successful checkpoint may record wrong free_segment value: - f2fs_write_checkpoint - f2fs_flush_sit_entries - do_checkpoint - ckpt->free_segment_count = cpu_to_le32(free_segments(sbi)); - f2fs_clear_prefree_segments - __set_test_and_free - free_i->free_segments++; I guess for the case of do_checkpoint() fails, maybe we can reset free segment to prefree status. Thoughts? Thanks, > > With this patch, for do_checkpoint fail: > > f2fs_write_checkpoint > ->f2fs_flush_sit_entries > ->do_checkpoint > ->f2fs_release_discard_addrs > > At this time, we did not mark prefree as free segments, so these segments will not be used. > > Thx >