From: Gao Xiang <gaoxiang25@huawei.com> To: Chao Yu <yuchao0@huawei.com> Cc: Chao Yu <chao@kernel.org>, <linux-erofs@lists.ozlabs.org>, Gao Xiang <xiang@kernel.org>, <linux-kernel@vger.kernel.org> Subject: Re: [PATCH v4] erofs: support superblock checksum Date: Mon, 28 Oct 2019 21:44:05 +0800 [thread overview] Message-ID: <20191028134405.GA186556@architecture4> (raw) In-Reply-To: <df7d7427-e7ca-5135-5db2-640eda30d253@huawei.com> Hi Chao, On Mon, Oct 28, 2019 at 08:36:00PM +0800, Chao Yu wrote: > On 2019/10/23 16:45, Gao Xiang wrote: <snip> > > That is quite a good point. :-) > > > > My first thought is to check the following payloads of sb (e.g, some per-fs > > metadata should be checked at mount time together. or for small images, check > > the whole image at the mount time) as well since if we introduce a new feature > > to some kernel version, forward compatibility needs to be considered. So it's > > better to make proper scalability, for this case, we have some choices: > > 1) limit `chksum_blocks' upbound at runtime (e.g. refuse >= 65536 blocks, > > totally 256M.) > > 2) just get rid of the whole `chksum_blocks' mess and checksum the first 4k > > at all, don't consider any latter scalability. > > Xiang, sorry for later reply... > > I prefer method 2), let's enable chksum feature only on superblock first, > chksum_blocks feature can be added later. Okay, got it. I will resend patch soon. Thanks, Gao Xiang > > Thanks, > > > > > Some perferred idea about this? I plan to release erofs-utils v1.0 tomorrow > > and hold up this feature for the next erofs-utils release, but I think we can > > get it ready for v5.5 since it is not quite complex feature... > > > > Thanks, > > Gao Xiang > > > > . > >
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <gaoxiang25@huawei.com> To: Chao Yu <yuchao0@huawei.com> Cc: Gao Xiang <xiang@kernel.org>, linux-erofs@lists.ozlabs.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4] erofs: support superblock checksum Date: Mon, 28 Oct 2019 21:44:05 +0800 [thread overview] Message-ID: <20191028134405.GA186556@architecture4> (raw) In-Reply-To: <df7d7427-e7ca-5135-5db2-640eda30d253@huawei.com> Hi Chao, On Mon, Oct 28, 2019 at 08:36:00PM +0800, Chao Yu wrote: > On 2019/10/23 16:45, Gao Xiang wrote: <snip> > > That is quite a good point. :-) > > > > My first thought is to check the following payloads of sb (e.g, some per-fs > > metadata should be checked at mount time together. or for small images, check > > the whole image at the mount time) as well since if we introduce a new feature > > to some kernel version, forward compatibility needs to be considered. So it's > > better to make proper scalability, for this case, we have some choices: > > 1) limit `chksum_blocks' upbound at runtime (e.g. refuse >= 65536 blocks, > > totally 256M.) > > 2) just get rid of the whole `chksum_blocks' mess and checksum the first 4k > > at all, don't consider any latter scalability. > > Xiang, sorry for later reply... > > I prefer method 2), let's enable chksum feature only on superblock first, > chksum_blocks feature can be added later. Okay, got it. I will resend patch soon. Thanks, Gao Xiang > > Thanks, > > > > > Some perferred idea about this? I plan to release erofs-utils v1.0 tomorrow > > and hold up this feature for the next erofs-utils release, but I think we can > > get it ready for v5.5 since it is not quite complex feature... > > > > Thanks, > > Gao Xiang > > > > . > >
next prev parent reply other threads:[~2019-10-28 13:41 UTC|newest] Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-10-22 18:06 [PATCH-v3] erofs: code for verifying superblock checksum of an erofs image Pratik Shinde 2019-10-22 18:06 ` Pratik Shinde 2019-10-23 4:05 ` [PATCH v4] erofs: support superblock checksum Gao Xiang 2019-10-23 4:05 ` Gao Xiang 2019-10-23 8:15 ` Chao Yu 2019-10-23 8:15 ` Chao Yu 2019-10-23 8:45 ` Gao Xiang 2019-10-23 8:45 ` Gao Xiang 2019-10-28 12:36 ` Chao Yu 2019-10-28 12:36 ` Chao Yu 2019-10-28 13:44 ` Gao Xiang [this message] 2019-10-28 13:44 ` Gao Xiang 2019-10-28 14:32 ` [PATCH v5] " Gao Xiang 2019-10-28 14:32 ` Gao Xiang 2019-10-30 2:33 ` Chao Yu 2019-10-30 2:33 ` Chao Yu 2019-10-30 2:56 ` Gao Xiang 2019-10-30 2:56 ` Gao Xiang 2019-10-30 5:08 ` [PATCH v6] " Gao Xiang 2019-10-30 5:08 ` Gao Xiang 2019-11-04 2:49 ` [PATCH v7] " Gao Xiang 2019-11-04 2:49 ` 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=20191028134405.GA186556@architecture4 \ --to=gaoxiang25@huawei.com \ --cc=chao@kernel.org \ --cc=linux-erofs@lists.ozlabs.org \ --cc=linux-kernel@vger.kernel.org \ --cc=xiang@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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.