Re: [RFC PATCH v2 0/5] Add option to use default config file.

["Darrick J. Wong" <djwong@kernel.org>]

On Fri, May 29, 2026 at 08:01:55PM +0200, Lukas Herbolt wrote:
> On 2026-05-28 07:10, Darrick J. Wong wrote:
> > On Mon, May 25, 2026 at 09:57:47AM +0200, Lukas Herbolt wrote:
> > > Hi,
> > > Sending a v2 version trying to implement the changes suggested by
> > > Carlos, Darrick, Eric and Dave. The default.conf is not installed
> > > automatically but there is simple example file.
> > > 
> > > The order is now build-time < default-file < command line settings.
> > > Some values like uuid,sunit,swidth sector size and block size are not
> > > allowed to be set in the default config file and if set user is warned
> > > about it and the value is reset to build-time default.
> > > 
> > > I moved setting of some values in cli_params and setting of
> > > mkfs_default_params
> > > into new bld_dft struct as If I get it correctly we were basically
> > > setting
> > > some of the default values on two places. It also  resulted in
> > > cleanup of
> > > unused parameters from some validate_* functions.
> > 
> > This looks mostly good, but I have a couple of suggestions to improve
> > the ergonomics for distributors:
> > 
> > 1. Make it so that mkfs.xfs itself can spit out a configuration file
> > based on the "bld_dft" object.  Then we can always generate the
> > "default.conf" file with something as simple as:
> > 
> > $ mkfs.xfs --write-defaults /root/my.conf
> > $ cat /root/my.conf
> > [metadata]
> > rmapbt=1
> > ...
> > 
> > Obviously this requires some careful thought about what exactly the
> > printing function will actually emit -- my guess is that the only things
> > worth printing are filesystem features and the default fsxattr values
> > that get written into the rootdir, since the device geometry will
> > change.
> 
> Make sense, but I would then remove the example file, also this comes to the
> fact while some (HW geometry) stuff are ignored in the default file. I would
> not allow user to set sector size sunit/swidth from the default file. The
> question
> is should we just exit with some info and calling usage() or set it to
> default
> and warn about it?

AFAICT, the config file parser currently allows you to provide fs
geometry options (e.g. sunit) in the config file.  I think we should
continue adding /any/ option that came from a config file, because if
that makes for an invalid geometry then mkfs will just complain about it
and error out.

But I wouldn't have a program that generates a config file capture
geometry information, at least not without a special switch (e.g.
--capture-exact-config).

> > 2. Make xfs_db/xfs_info emit a similar configuration file based on an
> > existing filesystem.  Anyone needing to create many feature-for-feature
> > replicas of an existing filesystem will now have a much easier time than
> > encoding options into a shell script.
> > 
> > # xfs_info -c 'writecfg' /my/rad/fs > /root/rad.conf
> > # mkfs.xfs -c options=/root/rad.conf /dev/sda
> > # mkfs.xfs -c options=/root/rad.conf /dev/sdb
> > ...
> > 
> > (maybe add an xfs_admin option to call xfs_{db,info} too?)
> > 
> > What do you think?
> > 
> 
> I guess xfs_{db,info} option which would be used in xfs_admin makes sense.
> But again here comes a question should we emit exact copy or leave HW
> geometry aside?

I'd only write out user-visible filesystem features since (at least in
our experience at $employer) customers usually require either specific
features or compatibility with an older kernel.

If someone really wants hw geometry then we can add that later. ;)

--D