---- 在 星期五, 2020-04-24 14:02:00 Amir Goldstein <amir73il@xxxxxxxxx> 撰写 ---- > > > > + case OPT_WHITEOUT_LINK_MAX: > > > > + if (match_int(&args[0], &link_max)) > > > > + return -EINVAL; > > > > + if (link_max < ovl_whiteout_link_max_def) > > > > + config->whiteout_link_max = link_max; > > > > > > Why not allow link_max > ovl_whiteout_link_max_def? > > > admin may want to disable ovl_whiteout_link_max_def by default > > > in module parameter, but allow it for specific overlay instances. > > > > > > > In this use case, seems we don't need module param any more, we just need to set default value for option. > > > > I would like to treate module param as a total switch, so that it could disable the feathre for all instances at the same time. > > I think sometimes it's helpful for lazy admin(like me). > > > > I am not convinced. > > lazy admin could very well want to disable whiteout_link_max by default, > but allow user to specify whiteout_link_max for a specific mount. > > In fact, in order to preserve existing behavior and not cause regression with > some special filesystems, distros could decide that default disabled is > a reasonable choice. > > I don't understand at all what the purpose of this limitation is. > If user sets a ridiculous link_max which is larger than valid range of upper fs, I think it is hard to verify in the stage of option parsing. So I hope to fix the upper limit using module parameter, we can set default mount option to 0/1 for the use case you mentioned above. Thanks, cgxu
