Re: erofs: Question on unused fields in on-disk structs

[Gao Xiang <gaoxiang25@huawei.com>]

Hi Ted,

On Thu, Aug 22, 2019 at 10:21:42AM -0400, Theodore Y. Ts'o wrote:
> On Thu, Aug 22, 2019 at 10:33:01AM +0200, Richard Weinberger wrote:
> > > super block chksum could be a compatible feature right? which means
> > > new kernel can support it (maybe we can add a warning if such image
> > > doesn't have a chksum then when mounting) but old kernel doesn't
> > > care it.
> > 
> > Yes. But you need some why to indicate that the chksum field is now
> > valid and must be used.
> > 
> > The features field can be used for that, but you don't use it right now.
> > I recommend to check it for being 0, 0 means then "no features".
> > If somebody creates in future a erofs with more features this code
> > can refuse to mount because it does not support these features.
> 
> The whole point of "compat" features is that the kernel can go ahead
> and mount the file system even if there is some new "compat" feature
> which it doesn't understand.  So the fact that right now erofs doesn't
> have any "compat" features means it's not surprising, and perfectly
> OK, if it's not referenced by the kernel.
> 
> For ext4, we have some more complex feature bitmasks, "compat",
> "ro_compat" (OK to mount read-only if there are features you don't
> understand) and "incompat" (if there are any bits you don't
> understand, fail the mount).  But since erofs is a read-only file
> system, things are much simpler.
> 
> It might make life easier for other kernel developers if "features"
> was named "compat_features" and "requirements" were named
> "incompat_features", just because of the long-standing use of that in
> ext2, ext3, ext4, ocfs2, etc.  But that naming scheme really is a
> legacy of ext2 and its descendents, and there's no real reason why it
> has to be that way on other file systems.

Thanks for your detailed explanation, thanks a lot!

Thanks,
Gao Xiang

> 
> Cheers,
> 
> 						- Ted