From: Gao Xiang <gaoxiang25@huawei.com> To: "Theodore Y. Ts'o" <tytso@mit.edu> Cc: Richard Weinberger <richard.weinberger@gmail.com>, Gao Xiang <hsiangkao@aol.com>, Richard Weinberger <richard@nod.at>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, <linux-erofs@lists.ozlabs.org>, linux-kernel <linux-kernel@vger.kernel.org> Subject: Re: erofs: Question on unused fields in on-disk structs Date: Thu, 22 Aug 2019 22:34:32 +0800 [thread overview] Message-ID: <20190822143432.GB195034@architecture4> (raw) In-Reply-To: <20190822142142.GB2730@mit.edu> 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
WARNING: multiple messages have this Message-ID (diff)
From: Gao Xiang <gaoxiang25@huawei.com> To: "Theodore Y. Ts'o" <tytso@mit.edu> Cc: Richard Weinberger <richard@nod.at>, linux-kernel <linux-kernel@vger.kernel.org>, linux-fsdevel <linux-fsdevel@vger.kernel.org>, linux-erofs@lists.ozlabs.org Subject: Re: erofs: Question on unused fields in on-disk structs Date: Thu, 22 Aug 2019 22:34:32 +0800 [thread overview] Message-ID: <20190822143432.GB195034@architecture4> (raw) In-Reply-To: <20190822142142.GB2730@mit.edu> 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
next prev parent reply other threads:[~2019-08-22 14:35 UTC|newest] Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-08-19 17:10 erofs: Question on unused fields in on-disk structs Richard Weinberger 2019-08-19 17:10 ` Richard Weinberger 2019-08-19 17:10 ` Richard Weinberger 2019-08-19 20:45 ` Gao Xiang 2019-08-19 20:45 ` Gao Xiang via Linux-erofs 2019-08-21 21:37 ` Richard Weinberger 2019-08-21 21:37 ` Richard Weinberger 2019-08-21 22:03 ` Gao Xiang 2019-08-21 22:03 ` Gao Xiang via Linux-erofs 2019-08-22 8:33 ` Richard Weinberger 2019-08-22 8:33 ` Richard Weinberger 2019-08-22 9:05 ` Gao Xiang 2019-08-22 9:05 ` Gao Xiang 2019-08-22 9:08 ` Gao Xiang 2019-08-22 9:08 ` Gao Xiang 2019-08-22 14:21 ` Theodore Y. Ts'o 2019-08-22 14:21 ` Theodore Y. Ts'o 2019-08-22 14:29 ` Richard Weinberger 2019-08-22 14:29 ` Richard Weinberger 2019-08-22 14:38 ` Gao Xiang 2019-08-22 14:38 ` Gao Xiang 2019-08-22 14:34 ` Gao Xiang [this message] 2019-08-22 14:34 ` 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=20190822143432.GB195034@architecture4 \ --to=gaoxiang25@huawei.com \ --cc=hsiangkao@aol.com \ --cc=linux-erofs@lists.ozlabs.org \ --cc=linux-fsdevel@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=richard.weinberger@gmail.com \ --cc=richard@nod.at \ --cc=tytso@mit.edu \ /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.