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. > 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
