On 2025/4/28 23:16, Gao Xiang wrote:
On Mon, Apr 28, 2025 at 02:25:45PM +0000, Hongbo Li wrote:
Some options are supported depending on different compiling config,
and these option will not fail during mount if they are not
supported. This is very weird, so we can reject them if they are
not supported.
If it's an invalid option, we should reject it immediately.
But for unsupported options, I don't think we always error
out. e.g. for some options like (acl, noacl) ext4 will just
ignore if ACL is unsupported.
Thanks for reviewing!
I will keep this in later version.
I think EROFS should follows that, otherwise users might use
"noacl" to disable ACL explicitly, but it will fail unexpectedly
if unsupported.
But I agree that for "fsid", "domain_id" and "directio", we
could error out instead.
Signed-off-by: Hongbo Li <lihongb...@huawei.com>
---
fs/erofs/super.c | 39 ++++++++++++++++++---------------------
1 file changed, 18 insertions(+), 21 deletions(-)
diff --git a/fs/erofs/super.c b/fs/erofs/super.c
index cadec6b1b554..c1c350c6fbf4 100644
--- a/fs/erofs/super.c
+++ b/fs/erofs/super.c
@@ -374,16 +374,26 @@ static const struct constant_table
erofs_dax_param_enums[] = {
};
static const struct fs_parameter_spec erofs_fs_parameters[] = {
+#ifdef CONFIG_EROFS_FS_XATTR
fsparam_flag_no("user_xattr", Opt_user_xattr),
+#endif
Another thing is that I'm not sure if "user_xattr" option is really
needed, we might just kill this option since all recent fses don't
have such configuration and user_xattrs should be supported by default.
Yeah, perhaps this option should be removed along with
CONFIG_EROFS_FS_XATTR, as xattr can be also consider as a type of data
that we cannot modify.
Thanks,
Hongbo
Thanks,
Gao Xiang
