From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.0 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5DEDACA9EAF for ; Thu, 24 Oct 2019 09:36:20 +0000 (UTC) Received: from lists.sourceforge.net (lists.sourceforge.net [216.105.38.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 2C05120684; Thu, 24 Oct 2019 09:36:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sourceforge.net header.i=@sourceforge.net header.b="jqHJPqM0"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=sf.net header.i=@sf.net header.b="KeCEaJGq" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 2C05120684 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linux-f2fs-devel-bounces@lists.sourceforge.net Received: from [127.0.0.1] (helo=sfs-ml-4.v29.lw.sourceforge.com) by sfs-ml-4.v29.lw.sourceforge.com with esmtp (Exim 4.90_1) (envelope-from ) id 1iNZXX-0004b6-Oj; Thu, 24 Oct 2019 09:36:19 +0000 Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-4.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1iNZXV-0004aN-CE for linux-f2fs-devel@lists.sourceforge.net; Thu, 24 Oct 2019 09:36:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sourceforge.net; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:CC:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ceexiL0aYdosgSYuDJnbfY/FYq40K6c/NCRJy4LyX1M=; b=jqHJPqM09zre+36NTWImwoPq5Z BRQ12JN8ZtWq1L2qRoGrHm4Qx+FBoZ4FKJe/GYwI22HpnNrunoYlpnyYoGGN6RSCrozTHb+pJZeu3 KJEsvnbhURULtUZoOVy3i70EbtAXYUoLWMTs/v4c65y7IJ9xmWTtLd7UYjQIwREkYYnk=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sf.net; s=x ; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:CC:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ceexiL0aYdosgSYuDJnbfY/FYq40K6c/NCRJy4LyX1M=; b=KeCEaJGqUshKiK6NJg9XSlsdtf 2ldX1XjjoGVUWM+25RE4lXsl65wkqbhGhoUAaY6CEn718QgMVjJZUsIEKxK9fAL5wK9spD0px6YQZ zb+7RyX8wXVLOA3QV8F+Xmpt5RtaYUrNXjCz+7EHamrwmv38g7bLm5d1D+0VR76y3Mh8=; Received: from szxga05-in.huawei.com ([45.249.212.191] helo=huawei.com) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92.2) id 1iNZXB-001Lls-8Y for linux-f2fs-devel@lists.sourceforge.net; Thu, 24 Oct 2019 09:36:14 +0000 Received: from DGGEMS411-HUB.china.huawei.com (unknown [172.30.72.60]) by Forcepoint Email with ESMTP id 3AFF2A86EB003757193A; Thu, 24 Oct 2019 17:35:50 +0800 (CST) Received: from [10.134.22.195] (10.134.22.195) by smtp.huawei.com (10.3.19.211) with Microsoft SMTP Server (TLS) id 14.3.439.0; Thu, 24 Oct 2019 17:35:45 +0800 To: Jaegeuk Kim References: <20191018063740.2746-1-shinichiro.kawasaki@wdc.com> <20191018063740.2746-7-shinichiro.kawasaki@wdc.com> <20191022170923.GB88771@jaegeuk-macbookpro.roam.corp.google.com> From: Chao Yu Message-ID: <05cfbde6-f8d2-c13d-ffc4-9fae5a17b98f@huawei.com> Date: Thu, 24 Oct 2019 17:35:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20191022170923.GB88771@jaegeuk-macbookpro.roam.corp.google.com> Content-Language: en-US X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected X-Headers-End: 1iNZXB-001Lls-8Y Subject: Re: [f2fs-dev] [PATCH v5 6/8] fsck: Check fsync data always for zoned block devices X-BeenThere: linux-f2fs-devel@lists.sourceforge.net X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Damien Le Moal , linux-f2fs-devel@lists.sourceforge.net Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net On 2019/10/23 1:09, Jaegeuk Kim wrote: > On 10/22, Chao Yu wrote: >> On 2019/10/18 14:37, Shin'ichiro Kawasaki wrote: >>> Fsck checks fsync data when UMOUNT flag is not set. When the f2fs was not >>> cleanly unmouted, UMOUNT flag is not recorded in meta data and fsync data >>> can be left in the f2fs. The first fsck run checks fsync data to reflect >>> it on quota status recovery. After that, fsck writes UMOUNT flag in the >>> f2fs meta data so that second fsck run can skip fsync data check. >> >> Oh, IMO, we need that flag to let fsck know there is still fsynced data in the >> image, could we just leave it as it is? >> >> To Jaegeuk, thoughts? > > I don't have objection to apply this patch. :P Anyway, looks my concern is another topic, let's go ahead with this patch. Reviewed-by: Chao Yu Thanks, > >> >> Thanks, >> >>> >>> However, fsck for zoned block devices need to care fsync data for all >>> fsck runs. The first fsck run checks fsync data, then fsck can check >>> write pointer consistency with fsync data. However, since second fsck run >>> does not check fsync data, fsck detects write pointer at fsync data end >>> is not consistent with f2fs meta data. This results in meta data update >>> by fsck and fsync data gets lost. >>> >>> To have fsck check fsync data always for zoned block devices, introduce >>> need_fsync_data_record() helper function which returns boolean to tell >>> if fsck needs fsync data check or not. For zoned block devices, always >>> return true. Otherwise, return true if UMOUNT flag is not set in CP. >>> Replace UMOUNT flag check codes for fsync data with the function call. >>> >>> Signed-off-by: Shin'ichiro Kawasaki >>> --- >>> fsck/fsck.h | 6 ++++++ >>> fsck/mount.c | 14 +++++++------- >>> fsck/segment.c | 2 +- >>> 3 files changed, 14 insertions(+), 8 deletions(-) >>> >>> diff --git a/fsck/fsck.h b/fsck/fsck.h >>> index 8da0ebb..75052d8 100644 >>> --- a/fsck/fsck.h >>> +++ b/fsck/fsck.h >>> @@ -133,6 +133,12 @@ enum seg_type { >>> >>> struct selabel_handle; >>> >>> +static inline bool need_fsync_data_record(struct f2fs_sb_info *sbi) >>> +{ >>> + return !is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG) || >>> + c.zoned_model == F2FS_ZONED_HM; >>> +} >>> + >>> extern int fsck_chk_orphan_node(struct f2fs_sb_info *); >>> extern int fsck_chk_quota_node(struct f2fs_sb_info *); >>> extern int fsck_chk_quota_files(struct f2fs_sb_info *); >>> diff --git a/fsck/mount.c b/fsck/mount.c >>> index 915f487..2979865 100644 >>> --- a/fsck/mount.c >>> +++ b/fsck/mount.c >>> @@ -1525,7 +1525,7 @@ int build_sit_info(struct f2fs_sb_info *sbi) >>> >>> bitmap_size = TOTAL_SEGS(sbi) * SIT_VBLOCK_MAP_SIZE; >>> >>> - if (!is_set_ckpt_flags(cp, CP_UMOUNT_FLAG)) >>> + if (need_fsync_data_record(sbi)) >>> bitmap_size += bitmap_size; >>> >>> sit_i->bitmap = calloc(bitmap_size, 1); >>> @@ -1540,7 +1540,7 @@ int build_sit_info(struct f2fs_sb_info *sbi) >>> sit_i->sentries[start].cur_valid_map = bitmap; >>> bitmap += SIT_VBLOCK_MAP_SIZE; >>> >>> - if (!is_set_ckpt_flags(cp, CP_UMOUNT_FLAG)) { >>> + if (need_fsync_data_record(sbi)) { >>> sit_i->sentries[start].ckpt_valid_map = bitmap; >>> bitmap += SIT_VBLOCK_MAP_SIZE; >>> } >>> @@ -1887,7 +1887,7 @@ void seg_info_from_raw_sit(struct f2fs_sb_info *sbi, struct seg_entry *se, >>> { >>> __seg_info_from_raw_sit(se, raw_sit); >>> >>> - if (is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG)) >>> + if (!need_fsync_data_record(sbi)) >>> return; >>> se->ckpt_valid_blocks = se->valid_blocks; >>> memcpy(se->ckpt_valid_map, se->cur_valid_map, SIT_VBLOCK_MAP_SIZE); >>> @@ -1903,7 +1903,7 @@ struct seg_entry *get_seg_entry(struct f2fs_sb_info *sbi, >>> >>> unsigned short get_seg_vblocks(struct f2fs_sb_info *sbi, struct seg_entry *se) >>> { >>> - if (is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG)) >>> + if (!need_fsync_data_record(sbi)) >>> return se->valid_blocks; >>> else >>> return se->ckpt_valid_blocks; >>> @@ -1911,7 +1911,7 @@ unsigned short get_seg_vblocks(struct f2fs_sb_info *sbi, struct seg_entry *se) >>> >>> unsigned char *get_seg_bitmap(struct f2fs_sb_info *sbi, struct seg_entry *se) >>> { >>> - if (is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG)) >>> + if (!need_fsync_data_record(sbi)) >>> return se->cur_valid_map; >>> else >>> return se->ckpt_valid_map; >>> @@ -1919,7 +1919,7 @@ unsigned char *get_seg_bitmap(struct f2fs_sb_info *sbi, struct seg_entry *se) >>> >>> unsigned char get_seg_type(struct f2fs_sb_info *sbi, struct seg_entry *se) >>> { >>> - if (is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG)) >>> + if (!need_fsync_data_record(sbi)) >>> return se->type; >>> else >>> return se->ckpt_type; >>> @@ -3242,7 +3242,7 @@ static int record_fsync_data(struct f2fs_sb_info *sbi) >>> struct list_head inode_list = LIST_HEAD_INIT(inode_list); >>> int ret; >>> >>> - if (is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG)) >>> + if (!need_fsync_data_record(sbi)) >>> return 0; >>> >>> ret = find_fsync_inode(sbi, &inode_list); >>> diff --git a/fsck/segment.c b/fsck/segment.c >>> index ccde05f..17c42b7 100644 >>> --- a/fsck/segment.c >>> +++ b/fsck/segment.c >>> @@ -62,7 +62,7 @@ int reserve_new_block(struct f2fs_sb_info *sbi, block_t *to, >>> se->type = type; >>> se->valid_blocks++; >>> f2fs_set_bit(offset, (char *)se->cur_valid_map); >>> - if (!is_set_ckpt_flags(F2FS_CKPT(sbi), CP_UMOUNT_FLAG)) { >>> + if (need_fsync_data_record(sbi)) { >>> se->ckpt_type = type; >>> se->ckpt_valid_blocks++; >>> f2fs_set_bit(offset, (char *)se->ckpt_valid_map); >>> > . > _______________________________________________ Linux-f2fs-devel mailing list Linux-f2fs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel