On Thu, May 11, 2017 at 04:08:59PM -0700, Luis R. Rodriguez wrote: > On Thu, May 11, 2017 at 3:57 PM, Eric Sandeen <sandeen@xxxxxxxxxxx> wrote: > > On 5/11/17 5:46 PM, Luis R. Rodriguez wrote: > > > >> FWIW, I've looked at ways to address this without your future work Jan, ie > >> backporting this feature, and ultimately have decided to *not* allow any > >> command line overwrite for options specified in the configuration file. So > >> for the backported versions of this feature a user will only be able to > >> overwrite if the config file is commented out or removed. > >> > >> How we end up doing this upstream may differ given we may have a way to > >> properly do sanity checks overall and treat "defaults" as real "defaults". > >> But without such mechanisms implementing a sensible way to overwrite things > >> in a compatible way was just crap. > >> > >> As such for the backported versions of this feature I'll make this big note > >> on the man page: > > > > I'm a little confused - backported from where to where? I'm not sure what > > a "backport" means in this context, when there is no upstream solution at this > > time. > > Since we're still waiting for a bit of delta before I can push this > work then from my development tree to a stable older release. > > >> """ > >> One of the uses of the configuration file is to enable distributions > >> to provide mkfs.xfs(8) updates from a base distribution release and enable to > >> create filesystems which are sure to remain supported and compatible. As such > >> systems with a mkfs.xfs.conf(5) file present have very likely been well thought > >> out, and overriding configuration file defaults is discouraged unless you > >> know what you are doing and are familiar with the associated risks. If you > >> know what you are doing, wish to waive compatibility, and wish to overwrite the > >> configuration file provided the best option is to either remove or uncomment > >> the configuration file completely as options cannot be overwritten on the > >> command line. > >> """ > > > > So are you planning a forked, non-upstream behavior for your distro? > > Right. Correct me if I'm wrong, but with this proposal we end up with the SuSE mkfs.xfs where if I write "rmapbt=0" in /etc/xfs.conf then I cannot later run `mkfs.xfs -m rmapbt=1` and have rmapbt turned on; whereas with the upstream mkfs.xfs if I write "rmapbt=0" in /etc/xfs.conf I /can/ later run `mkfs.fs -m rmapbt=1` and rmapbt gets turned on? That will create a lot of user script pain when command line options cause mkfs to fail in SuSE but they work fine everywhere else, right? --D > > > I think that disallowing commandline overrides of configfile settings is a > > mistake, and not what we'd want upstream. > > For upstream I agree. Its how config files typically work after all. > > > If you do it as a fork, mkfs should fail if conflicting options are specified, IMHO. > > Sure, conflict check will be retained given the same command line > option mechanism would be used to set whatever is in the config file. > > > The worst of all possible > > worlds is an admin typing an otherwise valid mkfs command, and getting a > > "successful" result which is /not/ what was specified by the user. > > Right. > > > Honestly, until an upstream solution is found, simply patching in new defaults > > seems safest (and least-element-of-surprise) for a distro. > > Thing is we have no such easy "default" mechanism today. In the future > it sounds like this will change so what you describe should be much > easier. Sure, today a few options are set to 0 on main(), but trying > to see when an option actually gets set to a default value if no other > options are set is non trivial. > > As for the backported approach, I don't expect the config file to > retain many options after all, only what is necessary to retain > compatibility with a base distro release. > > Luis > -- > To unsubscribe from this list: send the line "unsubscribe linux-xfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
