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

[Lukas Herbolt <lukas@herbolt.com>]

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?

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



-- 
-lhe