linux-f2fs-devel.lists.sourceforge.net archive mirror
 help / color / mirror / Atom feed
From: Chao Yu <chao@kernel.org>
To: Gao Xiang <gaoxiang25@huawei.com>,
	Jaegeuk Kim <jaegeuk@kernel.org>,
	"Yuchao (T)" <yuchao0@huawei.com>
Cc: "linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>,
	Gao Xiang <hsiangkao@aol.com>, heyunlei <heyunlei@huawei.com>,
	"linux-f2fs-devel@lists.sourceforge.net"
	<linux-f2fs-devel@lists.sourceforge.net>
Subject: Re: [PATCH] f2fs: use crc ^ cp_ver instead of crc | cp_ver for recovery
Date: Thu, 1 Feb 2018 22:29:15 +0800	[thread overview]
Message-ID: <84228ad0-b71c-dc49-5326-80e98d15ddd1@kernel.org> (raw)
In-Reply-To: <b4337b94-3f9c-9e18-3fff-76d230db576c@huawei.com>

On 2018/2/1 22:06, Gao Xiang wrote:
> 
> 
> On 2018/2/1 21:57, Gao Xiang wrote:
>> Hi Chao,
>>
>> On 2018/2/1 21:27, Chao Yu wrote:
>>> Hi Xiang,
>>>
>>> On 2018/2/1 0:16, Gaoxiang (OS) wrote:
>>>> This patch add a flag CP_CRC_RECOVERY_XOR_FLAG to use XORed crc ^ cp_ver
>>>> since crc | cp_ver is more likely to get a collision or become 11..1111 | cp_ver.
>>>
>>> FYI, we have discussed about this before:
>>>
>>> https://patchwork.kernel.org/patch/9342639/
>>>
>>> At that time, cp_ver will always be initialized with 1, so there is almost a
>>> little chance to use high 32 bits, result in less collision, so I think it
>>> will be OK.
>>>
>>> But now, cp_ver will be initialized with a random 64 bits value, then the
>>> collision will be increased, I agree that xor method will be better, but I'm
>>> not sure we should use this, since layout change makes complicated handling
>>> in codes for back compatibility.
>>>
>>> And do you encounter any incorrect recovery, or is there any following feature
>>> rely on this?
>>
> 
> 
> 
>> No... I just looked at node_footer because of another work and saw this part of code by chance.
>> I think XOR-ed calculation is much better in mathematics, and typical method for mixing two values (eg. XOR encryption) is also XOR-ed calculation rather than OR-ed...

Yes, I think so.

>>
>> Thanks,
>>
> 
> BTW,
> "The crc is already random enough, but has 32bits only.
> The cp_ver is not easy to use over 32bits, so we don't need to keep the other
> 32bits untouched in most of life."
> 
> I observe cp_ver(if the high 32 bits are 0) ^ crc == cp_ver | crc, but

We can use this calculation since cp_ver is complete 64-bits random number now.

Thanks,

> if cp_ver is over 32bits, ...
> 
> ...hmmm...
> 
> Thanks,
> 
>>>
>>> Thanks,
>>>
>>>>
>>>> Signed-off-by: Gao Xiang <gaoxiang25@huawei.com>
>>>> ---
>>>>   fs/f2fs/checkpoint.c    |  4 ++--
>>>>   fs/f2fs/node.h          | 16 +++++++++++-----
>>>>   fs/f2fs/segment.c       |  3 ++-
>>>>   include/linux/f2fs_fs.h |  1 +
>>>>   4 files changed, 16 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
>>>> index 8b0945b..9e7e63b 100644
>>>> --- a/fs/f2fs/checkpoint.c
>>>> +++ b/fs/f2fs/checkpoint.c
>>>> @@ -1157,8 +1157,8 @@ static void update_ckpt_flags(struct f2fs_sb_info *sbi, struct cp_control *cpc)
>>>>       if (is_sbi_flag_set(sbi, SBI_NEED_FSCK))
>>>>           __set_ckpt_flags(ckpt, CP_FSCK_FLAG);
>>>> -    /* set this flag to activate crc|cp_ver for recovery */
>>>> -    __set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG);
>>>> +    /* set this flag to activate crc^cp_ver for recovery */
>>>> +    __set_ckpt_flags(ckpt, CP_CRC_RECOVERY_XOR_FLAG);
>>>>       __clear_ckpt_flags(ckpt, CP_NOCRC_RECOVERY_FLAG);
>>>>       spin_unlock_irqrestore(&sbi->cp_lock, flags);
>>>> diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
>>>> index 081ef0d..7b9489f 100644
>>>> --- a/fs/f2fs/node.h
>>>> +++ b/fs/f2fs/node.h
>>>> @@ -293,8 +293,11 @@ static inline void fill_node_footer_blkaddr(struct page *page, block_t blkaddr)
>>>>       struct f2fs_node *rn = F2FS_NODE(page);
>>>>       __u64 cp_ver = cur_cp_version(ckpt);
>>>> -    if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG))
>>>> -        cp_ver |= (cur_cp_crc(ckpt) << 32);
>>>> +    if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_XOR_FLAG))
>>>> +        cp_ver ^= cur_cp_crc(ckpt) << 32;
>>>> +    /* for backward compatibility */
>>>> +    else if (unlikely(__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG)))
>>>> +        cp_ver |= cur_cp_crc(ckpt) << 32;
>>>>       rn->footer.cp_ver = cpu_to_le64(cp_ver);
>>>>       rn->footer.next_blkaddr = cpu_to_le32(blkaddr);
>>>> @@ -307,10 +310,13 @@ static inline bool is_recoverable_dnode(struct page *page)
>>>>       /* Don't care crc part, if fsck.f2fs sets it. */
>>>>       if (__is_set_ckpt_flags(ckpt, CP_NOCRC_RECOVERY_FLAG))
>>>> -        return (cp_ver << 32) == (cpver_of_node(page) << 32);
>>>> +        return (__u32)cp_ver == (__u32)cpver_of_node(page);
>>>> -    if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG))
>>>> -        cp_ver |= (cur_cp_crc(ckpt) << 32);
>>>> +    if (__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_XOR_FLAG))
>>>> +        cp_ver ^= cur_cp_crc(ckpt) << 32;
>>>> +    /* for backward compatibility */
>>>> +    else if (unlikely(__is_set_ckpt_flags(ckpt, CP_CRC_RECOVERY_FLAG)))
>>>> +        cp_ver |= cur_cp_crc(ckpt) << 32;
>>>>       return cp_ver == cpver_of_node(page);
>>>>   }
>>>> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
>>>> index 205b0d9..64d0c1f 100644
>>>> --- a/fs/f2fs/segment.c
>>>> +++ b/fs/f2fs/segment.c
>>>> @@ -2316,7 +2316,8 @@ static void allocate_segment_by_default(struct f2fs_sb_info *sbi,
>>>>       if (force)
>>>>           new_curseg(sbi, type, true);
>>>> -    else if (!is_set_ckpt_flags(sbi, CP_CRC_RECOVERY_FLAG) &&
>>>> +    else if (!(is_set_ckpt_flags(sbi, CP_CRC_RECOVERY_FLAG) ||
>>>> +        is_set_ckpt_flags(sbi, CP_CRC_RECOVERY_XOR_FLAG)) &&
>>>>                       type == CURSEG_WARM_NODE)
>>>>           new_curseg(sbi, type, false);
>>>>       else if (curseg->alloc_type == LFS && is_next_segment_free(sbi, type))
>>>> diff --git a/include/linux/f2fs_fs.h b/include/linux/f2fs_fs.h
>>>> index f7f0990..07ddf4b 100644
>>>> --- a/include/linux/f2fs_fs.h
>>>> +++ b/include/linux/f2fs_fs.h
>>>> @@ -117,6 +117,7 @@ struct f2fs_super_block {
>>>>   /*
>>>>    * For checkpoint
>>>>    */
>>>> +#define CP_CRC_RECOVERY_XOR_FLAG    0x00000800
>>>>   #define CP_LARGE_NAT_BITMAP_FLAG    0x00000400
>>>>   #define CP_NOCRC_RECOVERY_FLAG    0x00000200
>>>>   #define CP_TRIMMED_FLAG        0x00000100
>>>>

------------------------------------------------------------------------------
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

  reply	other threads:[~2018-02-01 14:29 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-31 16:16 [f2fs-dev] [PATCH] f2fs: use crc ^ cp_ver instead of crc | cp_ver for recovery Gaoxiang (OS)
2018-02-01 13:27 ` Chao Yu
2018-02-01 13:57   ` Gao Xiang
2018-02-01 14:06     ` [f2fs-dev] " Gao Xiang
2018-02-01 14:29       ` Chao Yu [this message]
2018-02-01 14:30         ` Chao Yu
2018-02-01 14:38           ` Gao Xiang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84228ad0-b71c-dc49-5326-80e98d15ddd1@kernel.org \
    --to=chao@kernel.org \
    --cc=gaoxiang25@huawei.com \
    --cc=heyunlei@huawei.com \
    --cc=hsiangkao@aol.com \
    --cc=jaegeuk@kernel.org \
    --cc=linux-f2fs-devel@lists.sourceforge.net \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=yuchao0@huawei.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).