Re: [PATCH 0/9] mkfs.xfs: add mkfs.xfs.conf support

["Darrick J. Wong" <darrick.wong@oracle.com>]

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@sandeen.net> 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@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html