From: Jan Kara <jack@suse.cz>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: "Luis R. Rodriguez" <mcgrof@kernel.org>,
linux-xfs@vger.kernel.org, jack@suse.com, jeffm@suse.com,
okurz@suse.com, lpechacek@suse.com
Subject: Re: [PATCH 0/9] mkfs.xfs: add mkfs.xfs.conf support
Date: Mon, 6 Mar 2017 09:50:01 +0100 [thread overview]
Message-ID: <20170306085001.GB14932@quack2.suse.cz> (raw)
In-Reply-To: <6de0c7e4-8d20-ea90-fc49-d47a787e3939@sandeen.net>
On Fri 03-03-17 21:49:58, Eric Sandeen wrote:
> On 3/3/17 5:13 PM, Luis R. Rodriguez wrote:
> > This series adds mkfs.xfs.conf support, so that options can now be
> > shoved into a configuration file. This enables certain defaults to be
> > saved for folks sticking to certain values, but more importantly it
> > also enables distributions to override certain defaults so that new
> > filesystems remain compatible with older distributions.
> >
> > This has been based on top of xfsprogs-dev v4.9.0-rc1.
> >
> > Given we already have an existinsg infrastructure to validate argument
> > values this reuses that infrastructure by first adding helpers and porting
> > over the argument parsing suppor to use these helpers.
>
> I'm not necessarily the final word on this, but I have to say
> I'm not a huge fan of having mkfs config files. I've lived
> through that in mke2fs land, and my personal feeling is that
> it can lead to confusion when distros start shipping config
> files with different defaults than upstream ships in the
> code itself.
>
> I guess I can see the argument for shipping old/compatible
> defaults with newer progs and older kernels, but by the
> time a distro ships a custom old default config file they could
> also patch out the new features just as easily... (which
> is also confusing, I guess ;) )
Yeah, patching sources is IMO more confusing than changing config files.
You can at least easily ask for the contents of the config file... Also
when analysing XFS issue, you ask for xfs_info output anyway as that is the
only way how to be *sure* which features the fs has enabled and mkfs config
file does not invalidate that.
> After 25+ years of no external config file, I'm concerned
> about principal of least surprise when the same xfsprogs version
> starts behaving differently on different boxes based on a new
> file that popped up in /etc ...
>
> At the very least, I would like to /not/ ship or install any
> config file with xfsprogs by default; the code itself should
> be the canonical, single point of truth for defaults for a stock
> "make && make install" installation.
Agree with that.
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2017-03-06 10:02 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-03 23:13 [PATCH 0/9] mkfs.xfs: add mkfs.xfs.conf support Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 1/9] mkfs.xfs: add helper to parse command line options Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 2/9] mkfs.xfs: move dopts to struct mkfs_xfs_opts Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 3/9] mkfs.xfs: move iopts to " Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 4/9] mkfs.xfs: move lopts " Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 5/9] mkfs.xfs: move mopts " Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 6/9] mkfs.xfs: move nopts " Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 7/9] mkfs.xfs: move ropts " Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 8/9] mkfs.xfs: use parse_subopts() to parse sopts Luis R. Rodriguez
2017-03-03 23:13 ` [PATCH 9/9] mkfs.xfs: add mkfs.xfs.conf parse support Luis R. Rodriguez
2017-03-03 23:55 ` Dave Chinner
2017-03-09 5:38 ` Eric Sandeen
2017-03-03 23:24 ` [PATCH 0/9] mkfs.xfs: add mkfs.xfs.conf support Luis R. Rodriguez
2017-03-04 3:49 ` Eric Sandeen
2017-03-04 4:56 ` Dave Chinner
2017-03-06 0:08 ` Eric Sandeen
2017-03-07 20:07 ` Jeff Mahoney
2017-03-07 20:09 ` Eric Sandeen
2017-03-06 8:50 ` Jan Kara [this message]
2017-03-09 0:16 ` Eric Sandeen
2017-03-09 0:51 ` Luis R. Rodriguez
2017-03-09 4:41 ` Eric Sandeen
2017-03-09 10:12 ` Jan Tulak
2017-03-09 14:31 ` Eric Sandeen
2017-03-09 15:21 ` Jan Tulak
2017-03-09 17:57 ` Luis R. Rodriguez
2017-03-09 22:34 ` Dave Chinner
2017-04-24 5:00 ` Luis R. Rodriguez
2017-04-24 7:26 ` Jan Tulak
2017-04-24 8:25 ` Luis R. Rodriguez
2017-05-11 22:46 ` Luis R. Rodriguez
2017-05-11 22:57 ` Eric Sandeen
2017-05-11 23:08 ` Luis R. Rodriguez
2017-05-12 0:48 ` Darrick J. Wong
2017-05-12 16:05 ` Eric Sandeen
2017-05-12 17:03 ` Luis R. Rodriguez
2017-05-12 17:05 ` Jeff Mahoney
2017-05-12 17:30 ` Luis R. Rodriguez
2017-05-11 23:00 ` Darrick J. Wong
2017-05-11 23:19 ` Luis R. Rodriguez
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170306085001.GB14932@quack2.suse.cz \
--to=jack@suse.cz \
--cc=jack@suse.com \
--cc=jeffm@suse.com \
--cc=linux-xfs@vger.kernel.org \
--cc=lpechacek@suse.com \
--cc=mcgrof@kernel.org \
--cc=okurz@suse.com \
--cc=sandeen@sandeen.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.