From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754110AbdCFKZk (ORCPT ); Mon, 6 Mar 2017 05:25:40 -0500 Received: from szxga01-in.huawei.com ([45.249.212.187]:3823 "EHLO dggrg01-dlp.huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1754029AbdCFKZd (ORCPT ); Mon, 6 Mar 2017 05:25:33 -0500 Subject: Re: [PATCH] f2fs: correct cp_ver for compatibility to old image To: Jaegeuk Kim References: <20170302032233.89189-1-yuchao0@huawei.com> <20170302185518.GA1030@jaegeuk.local> CC: , , From: Chao Yu Message-ID: <2b7a24e8-9c85-9646-059b-153a4f796bef@huawei.com> Date: Mon, 6 Mar 2017 18:23:03 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20170302185518.GA1030@jaegeuk.local> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.134.22.195] X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58BD388D.01F4,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0, ip=0.0.0.0, so=2014-11-16 11:51:01, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6ead7cb008c504809ee8fb2b82fcad9d Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2017/3/3 2:55, Jaegeuk Kim wrote: > On 03/02, Chao Yu wrote: >> There is no CP_CRC_RECOVERY_FLAG tagged in checkpoint pack, calculate >> cp_version as old format. >> >> Signed-off-by: Chao Yu >> --- >> fs/f2fs/node.c | 4 +++- >> 1 file changed, 3 insertions(+), 1 deletion(-) >> >> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c >> index 6c027b6833f4..0d46404ca769 100644 >> --- a/fs/f2fs/node.c >> +++ b/fs/f2fs/node.c >> @@ -2507,7 +2507,9 @@ static int __get_nat_bitmaps(struct f2fs_sb_info *sbi) >> f2fs_put_page(page, 1); >> } >> >> - cp_ver |= (cur_cp_crc(ckpt) << 32); >> + if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG)) >> + cp_ver |= (cur_cp_crc(ckpt) << 32); > > Well, we always write nat_bits with crc. So if it's different, something is > wrong and we need to drop it. Got it. :) Thanks, > CP-CRC_RECOVERY_FLAG is used for roll-forward recovery, which is a different context. > >> + >> if (cpu_to_le64(cp_ver) != *(__le64 *)nm_i->nat_bits) { >> disable_nat_bits(sbi, true); >> return 0; >> -- >> 2.8.2.295.g3f1c1d0 > > . >