Re: [RFC PATCH 1/1] xfsprogs: mkfs.xfs add default configuration file.

[Dave Chinner <dgc@kernel.org>]

On Thu, May 14, 2026 at 11:05:14AM -0500, Eric Sandeen wrote:
> On 5/14/26 10:21 AM, Carlos Maiolino wrote:
> > On Thu, May 14, 2026 at 04:37:17PM +0200, Lukas Herbolt wrote:
> >> Various users may prefer different default values. Having a default config
> >> file will allow them to utilize it without the need specifying configuration
> >> file on command line.
> >>
> > The idea seems reasonable, to have a default file to load if it's found.
> > I just particularly don't like the idea of shipping/installing a 'default'
> > config file.
> > I think we could ship an "example" one, but leave to distributions to decide
> > what to do. If they would install a default config or not. And maintain
> > the default config file.
> > LTS configs are easy to maintain because we know no new features will be
> > ported to LTS. Providing a default config file from the mainline risks
> > getting a lot of user complains if we in the future decide to change the
> > 'defaults' of the default config file.
> 
> Thanks for starting this discussion Lukas.
> 
> I'm sure others will have Deeper Thoughts but I more or less agree with
> Carlos here - a default config file to be loaded /if it exists/ but maybe
> not existing by default - because we already have defaults hardcoded into
> the binary itself - might be a more maintainable path for upstream.

Yes, the upstream package should not install a defaults file - the
package might be built alongside the system package install using an
install prefix, and we don't want to be overriding any config the
user/distro has already installed.

> Otherwise I see new tests appearing which are like "make sure the dfault
> config we ship matches the defaults built into the binary itself" which
> seems like unneeded complexity.
> 
> (i.e. the os-specific config files could be renamed or symlinked to
> that special default config file path, for example?)
> 
> I could maybe see generating an example defaults config file which matches
> the built-in defaults at build time? Not sure if that would be useful
> or helpful (or complex).

Not really useful, IMO, because changing default behaviour is a
relatively rare event.

Indeed, we already have LTS kernel mkfs conf files that adjust "cli"
parameters to match the mkfs defaults at the time the LTS kernel was
released. These get installed into /usr/share/xfsprogs/mkfs for
users that want to use them via 'mkfs.xfs -c ..../lts_6.12.conf
...'.

Hence I don't think we even need to care about maintaining conf
files for the current defaults or even per-package-release files
because what most people care about is maintaining a feature set
that is compatible with the distro kernel(s) they are running...

Hence if we are going to ship default config files that users can
install manually into /etc/xfs/mkfs/default.conf, then the package
install directory for those example config files would also be
/usr/share/xfsprogs/mkfs, right?

If that is the case, how does the user now tell the difference
between a CLI conf file and a template default conf file that
should be installed into /etc/xfsprogs/mkfs/.... to change the
default behaviour to match lts_6.12.conf?

I guess what I'm asking is that the conf file we install into /etc
to set the defaults needs to have exactly the same contents as the
conf file the user would specify on the command line to get that
specific config to be used.

If this is already the case with this new proposal, then we don't
need to ship any new example config files, just hook up an xfs_admin
command to set a specific conf file as the mkfs default. i.e. to set
the default behaviour to 6.12 compatible:

# xfs_admin -d /usr/share/xfsprogs/mkfs/lts_6.12.conf

And to reset mkfs behaviour back to built in defaults:

# xfs_admin -d clear

Distros can then patch their package source to add their own
defaults files for their own releases - we could even ask distros to
push them upstream so that users can still use bleeding edge
xfsprogs on older distros when needed....

Cheers,

Dave.
-- 
Dave Chinner
dgc@kernel.org