On Thu, Aug 22, 2019 at 05:05:41PM +0800, Gao Xiang wrote:
[]
> >
> > But be very sure that existing erofs filesystems actually have this field
> > set to 0 or something other which is always the same.
> > Otherwise you cannot use the field anymore because it could be anything.
> > A common bug is that the mkfs program keeps such unused fields
> > uninitialized and then it can be a more or less random value without
> > notice.
>
> Why? In my thought, the logic is that
> - v4.3, "features" that kernel can handle is 0, so chksum is unused (DONTCARE field)
> and chksum field could be anything, but the kernel doesn't care.
- sorry, I meant linux <= v5.3. add a word....
Thanks,
Gao Xiang
>
> - later version, add an extra compat feature to "features" to indicate SB_CHKSUM
> is now valid, such as EROFS_FEATURE_SB_CHKSUM (rather than requirements, it's
> incompat), so the kernel can check the checksum like that:
>
> if (feature & EROFS_FEATURE_SB_CHKSUM) { /* chksum is set */
> if (chk crc32c and no match) {
> return -EFSBADCRC;
> }
> go ahead
> } else {
> /* still don't care chksum field but print the following warning to kmsg */
> warnln("You are mounting a image without super_block chksum, please take care!!!!");
>
> or maybe we can even refuse mount these images, except for some mount option
> such as "force-mount".
> }
>
> That is also what F2FS did recently, refer the following commit
> commit d440c52d3151("f2fs: support superblock checksum")
>
> >
> > > Or maybe you mean these reserved fields? I have no idea all other
> > > filesystems check these fields to 0 or not... But I think it should
> > > be used with some other flag is set rather than directly use, right?
> >
> > Basically you want a way to know when a field shall be used and when not.
> > Most filesystems have version/feature fields. Often multiple to denote different
> > levels of compatibility.
>
> On-disk inode has i_advise field, and super_block has
> "features" and "requirements" fields. we can use some of them
> or any combinations.
>
> Thanks,
> Gao Xiang
>
> >
> > --
> > Thanks,
> > //richard
