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
