mkfs.xfs: add mkfs.xfs.conf parse support using libini_config
RFC v2 1/1 mkfs.xfs: add mkfs.xfs.conf parse support using libini_config
You may want to stick to specific set of configuration options when creating filesystems with mkfs.xfs -- sometimes due to pure technical reasons, but some other times to ensure systems remain compatible as new features are introduced with older kernels, or if you always want to take advantage of some new feature which would otherwise typically be disruptive.
Although mkfs.xfs already uses sensible defaults this adds a configuration option for parsing defaults settings for mkfs.xfs parsed prior to processing input arguments from the command line.
We define an XFS configuration directory, /etc/mkfs.xfs.d/ and allow for different types of configuration files, if none is specified we look for the default type, /etc/mkfs.xfs.d/default, and you can override with -t. For instance if you specify:
mkfs.xfs -t experimental -f /dev/loop0
The file /etc/mkfs.xfs.d/experimental will be used as your configuration file. If you really need to override the full path of the configuration file you may use the MKFS_XFS_CONFIG enviornment variable.
To use /etc/ be sure to configure xfsprogs with:
./configure --sysconfdir=/etc/
To verify what configuration file is used on a system use the typical:
mkfs.xfs -N
There is only a subset of options allowed to be set on the conifiguration file, and currently only 1 or 0 are acceptable values. They are:
[data]
noalign=
[inode]
align=
attr=
projid32bit=
sparse=
[log]
lazy-count=
version=
[metadata]
crc=
finobt=
rmapbt=
reflink=
[naming]
ftype=
[rtdev]
noalign=
---
So here is a follow up on the configuration front, now that the code refactor is merged. I've used libini_config for an initial evaluation.
The big difference is I'm limitting configuration settings to only a set of bools which are set via the default params. This simplifies parsing considerably given we don't have to re-use the internal setters and checkers, instead this is done later at processing time. There are other reasons to now allow for configuring other parameters -- the fact that some have dependency on others.
If we *really* intended to support parsing more options, we need to deal with the last seen bit, and making the code much more complex.
For the life of me I couldn't get the @libiniconfig@ autoconf thing to parse. Could use a second pair of eyeballs on that.
Let's bikeshed on this now.
configure.ac | 3 + include/builddefs.in | 5 + m4/Makefile | 1 + m4/package_ini_config.m4 | 20 +++ m4/package_pthread.m4 | 2 +- man/man8/mkfs.xfs.8 | 23 +++ mkfs/Makefile | 2 +- mkfs/xfs_mkfs.c | 408 ++++++++++++++++++++++++++++++++++++++++++++--- 8 files changed, 443 insertions(+), 21 deletions(-) create mode 100644 m4/package_ini_config.m4
configure.ac +3 -0
@@ -142,6 +142,9 @@ AC_PACKAGE_NEED_UUIDCOMPARE AC_PACKAGE_NEED_PTHREAD_H AC_PACKAGE_NEED_PTHREADMUTEXINIT +AC_PACKAGE_NEED_LIBINI_CONFIG_H +AC_PACKAGE_NEED_INICONFIGGETSTAT + AC_HAVE_FADVISE AC_HAVE_MADVISE AC_HAVE_MINCORE
include/builddefs.in +5 -0
@@ -30,6 +30,9 @@ BUILD_CFLAGS = @BUILD_CFLAGS@ -D_FILE_OFFSET_BITS=64 LIBRT = @librt@ LIBUUID = @libuuid@ +# Can't figure out why this won't work yet. +#LIBINICONFIG = @libiniconfig@ +LIBINICONFIG = -lini_config -lbasicobjects -lref_array -lcollection LIBPTHREAD = @libpthread@ LIBTERMCAP = @libtermcap@ LIBEDITLINE = @libeditline@
@@ -63,6 +66,7 @@ PKG_LIB_DIR = @libdir@@libdirsuffix@ PKG_INC_DIR = @includedir@/xfs DK_INC_DIR = @includedir@/disk PKG_MAN_DIR = @mandir@ +PKG_ETC_DIR = @sysconfdir@ PKG_DOC_DIR = @datadir@/doc/@pkg_name@ PKG_LOCALE_DIR = @datadir@/locale
@@ -178,6 +182,7 @@ SANITIZER_LDFLAGS += @addrsan_ldflags@ @threadsan_ldflags@ @ubsan_ldflags@ GCFLAGS = $(DEBUG) \ -DVERSION=\"$(PKG_VERSION)\" -DLOCALEDIR=\"$(PKG_LOCALE_DIR)\" \ + -DROOT_SYSCONFDIR=\"$(PKG_ETC_DIR)\" \ -DPACKAGE=\"$(PKG_NAME)\" -I$(TOPDIR)/include -I$(TOPDIR)/libxfs ifeq ($(ENABLE_GETTEXT),yes)
m4/Makefile +1 -0
@@ -26,6 +26,7 @@ LSRCFILES = \ package_unistring.m4 \ package_utilies.m4 \ package_uuiddev.m4 \ + package_ini_config.m4 \ multilib.m4 \ $(CONFIGURE)
m4/package_ini_config.m4 new file +20 -0
@@ -0,0 +1,20 @@ +AC_DEFUN([AC_PACKAGE_NEED_LIBINI_CONFIG_H], + [ AC_CHECK_HEADERS([ini_configobj.h]) + if test $ac_cv_header_ini_configobj_h = no ; then + AC_CHECK_HEADERS(ini_configobj.h,, [ + echo 'FATAL ERROR: could not find a valid libini_config header.' + echo 'Install the libini_config development package.' + exit 1]) + fi + ]) + +AC_DEFUN([AC_PACKAGE_NEED_INICONFIGGETSTAT], + [ + AC_CHECK_LIB([ini_config], + [ini_config_get_stat], + [libiniconfig=-lini_config -lbasicobjects -lref_array -lcollection], [ + echo + echo 'FATAL ERROR: could not find a valid libini_config library.' + exit 1]) + AC_SUBST(libiniconfig) + ])
m4/package_pthread.m4 +1 -1
@@ -1,7 +1,7 @@ AC_DEFUN([AC_PACKAGE_NEED_PTHREAD_H], [ AC_CHECK_HEADERS(pthread.h) if test $ac_cv_header_pthread_h = no; then - AC_CHECK_HEADERS(pthread.h,, [ + AC_CHECK_HEADERS(ini_configobj.h,, [ echo echo 'FATAL ERROR: could not find a valid pthread header.' exit 1])
man/man8/mkfs.xfs.8 +23 -0
@@ -83,6 +83,23 @@ and .B \-l internal \-l size=10m are equivalent. .PP +An optional XFS configuration type file directory +.B mkfs.xfs.d (5) +exists to help fine tune default parameters which can be used when calling +.B mkfs.xfs (8), by default type will be used by default, /etc/mkfs.xfs.d/default. +Command line arguments directly passed to +.B mkfs.xfs (8) +will always override parameters set it the configuration type file. +You can override configuration file type on the +.B mkfs.xfs.d (5) +directory by using the -t parameter and secifying the type. Alternatively +you can set and use the MKFS_XFS_CONFIG environment variable to override +the default full path of the first file +.B mkfs.xfs (8) +looks for. +If you use -t the type configuration file must be present under +.B mkfs.xfs.d (8). +.PP In the descriptions below, sizes are given in sectors, bytes, blocks, kilobytes, megabytes, gigabytes, etc. Sizes are treated as hexadecimal if prefixed by 0x or 0X,
@@ -123,6 +140,11 @@ Many feature options allow an optional argument of 0 or 1, to explicitly disable or enable the functionality. .SH OPTIONS .TP +.BI \-t " configuration-type" +Override the default type of the configuratio file under +.B mkfs.xfs.d +used. +.TP .BI \-b " block_size_options" This option specifies the fundamental block size of the filesystem. The valid
@@ -923,6 +945,7 @@ Prints the version number and exits. .SH SEE ALSO .BR xfs (5), .BR mkfs (8), +.BR mkfs.xfs.d (5), .BR mount (8), .BR xfs_info (8), .BR xfs_admin (8).
mkfs/Makefile +1 -1
@@ -11,7 +11,7 @@ HFILES = CFILES = proto.c xfs_mkfs.c LLDLIBS += $(LIBXFS) $(LIBXCMD) $(LIBFROG) $(LIBRT) $(LIBPTHREAD) $(LIBBLKID) \ - $(LIBUUID) + $(LIBUUID) $(LIBINICONFIG) LTDEPENDENCIES += $(LIBXFS) $(LIBXCMD) $(LIBFROG) LLDFLAGS = -static-libtool-libs
mkfs/xfs_mkfs.c +389 -19
545 lines not on this page · raw message
Signature · 1 line
2.16.2
Quoted 11 lines · Luis R. Rodriguez
You may want to stick to specific set of configuration options when creating filesystems with mkfs.xfs -- sometimes due to pure technical reasons, but some other times to ensure systems remain compatible as new features are introduced with older kernels, or if you always want to take advantage of some new feature which would otherwise typically be disruptive.
Although mkfs.xfs already uses sensible defaults this adds a configuration option for parsing defaults settings for mkfs.xfs parsed prior to processing input arguments from the command line.
Quoted 6 lines
We define an XFS configuration directory,
/etc/mkfs.xfs.d/and allow for different types of configuration files, if none is specified we look for the default type,/etc/mkfs.xfs.d/default, and you can override with -t. For instance if you specify:mkfs.xfs -t experimental -f
/dev/loop0
I haven't looked at the code at all, but I'll just make this initial comment now: please don't use "-t" with mkfs.xfs.
"-t <type>" is a reserved flag used by the mkfs multiplexor to specify the filesystem type, and so cannot be passed to filesystem specific mkfs binaries. Hence we should not be using it in the mkfs.xfs binary.
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]
Quoted 33 lines · Luis R. Rodriguez
You may want to stick to specific set of configuration options when creating filesystems with mkfs.xfs -- sometimes due to pure technical reasons, but some other times to ensure systems remain compatible as new features are introduced with older kernels, or if you always want to take advantage of some new feature which would otherwise typically be disruptive.
Although mkfs.xfs already uses sensible defaults this adds a configuration option for parsing defaults settings for mkfs.xfs parsed prior to processing input arguments from the command line.
We define an XFS configuration directory,
/etc/mkfs.xfs.d/and allow for different types of configuration files, if none is specified we look for the default type,/etc/mkfs.xfs.d/default, and you can override with -t. For instance if you specify:mkfs.xfs -t experimental -f
/dev/loop0The file
/etc/mkfs.xfs.d/experimentalwill be used as your configuration file. If you really need to override the full path of the configuration file you may use theMKFS_XFS_CONFIGenviornment variable.To use
/etc/be sure to configure xfsprogs with:./configure --sysconfdir=/etc/
To verify what configuration file is used on a system use the typical:
mkfs.xfs -N
There is only a subset of options allowed to be set on the conifiguration file, and currently only 1 or 0 are acceptable values. They are:
Quoted 8 lines
[data]
noalign=[inode]
align=
attr=
projid32bit=
sparse=
Hey, can I ask a maybe ridiculous question ...
What's the advantage of haggling over ini file parsers and file formats, vs. just:
# echo "-m crc=0 -n ftype=0" > /etc/mkfs.xfs.d/default
and parse that into defaults exactly as if it had been on the commandline?
-Eric
Quoted 43 lines · Eric Sandeen
Quoted 33 lines · Luis R. Rodriguez
You may want to stick to specific set of configuration options when creating filesystems with mkfs.xfs -- sometimes due to pure technical reasons, but some other times to ensure systems remain compatible as new features are introduced with older kernels, or if you always want to take advantage of some new feature which would otherwise typically be disruptive.
Although mkfs.xfs already uses sensible defaults this adds a configuration option for parsing defaults settings for mkfs.xfs parsed prior to processing input arguments from the command line.
We define an XFS configuration directory,
/etc/mkfs.xfs.d/and allow for different types of configuration files, if none is specified we look for the default type,/etc/mkfs.xfs.d/default, and you can override with -t. For instance if you specify:mkfs.xfs -t experimental -f
/dev/loop0The file
/etc/mkfs.xfs.d/experimentalwill be used as your configuration file. If you really need to override the full path of the configuration file you may use theMKFS_XFS_CONFIGenviornment variable.To use
/etc/be sure to configure xfsprogs with:./configure --sysconfdir=/etc/
To verify what configuration file is used on a system use the typical:
mkfs.xfs -N
There is only a subset of options allowed to be set on the conifiguration file, and currently only 1 or 0 are acceptable values. They are:
Quoted 8 lines
[data]
noalign=[inode]
align=
attr=
projid32bit=
sparse=
Quoted 7 lines
Hey, can I ask a maybe ridiculous question ...
What's the advantage of haggling over ini file parsers and file formats, vs. just:
# echo "-m crc=0 -n ftype=0" > /etc/mkfs.xfs.d/defaultand parse that into defaults exactly as if it had been on the commandline?
Except for having to break that up into individual argv-like strings, I too was wondering if that would be the simplest answer. Same syntax, same parsing of number-with-units, etc.
Should we run getopt ahead of time to pick out the -T arg so that we always load the settings file before we start processing the rest of the cli options? So that:
# mkfs.xfs -m crc=1 -T default /dev/sda
actually formats a v5 fs?
--D
Quoted 6 lines
-Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 44 lines · Darrick J. Wong
Quoted 43 lines · Eric Sandeen
Quoted 41 lines · Luis R. Rodriguez
You may want to stick to specific set of configuration options when creating filesystems with mkfs.xfs -- sometimes due to pure technical reasons, but some other times to ensure systems remain compatible as new features are introduced with older kernels, or if you always want to take advantage of some new feature which would otherwise typically be disruptive.
Although mkfs.xfs already uses sensible defaults this adds a configuration option for parsing defaults settings for mkfs.xfs parsed prior to processing input arguments from the command line.
We define an XFS configuration directory,
/etc/mkfs.xfs.d/and allow for different types of configuration files, if none is specified we look for the default type,/etc/mkfs.xfs.d/default, and you can override with -t. For instance if you specify:mkfs.xfs -t experimental -f
/dev/loop0The file
/etc/mkfs.xfs.d/experimentalwill be used as your configuration file. If you really need to override the full path of the configuration file you may use theMKFS_XFS_CONFIGenviornment variable.To use
/etc/be sure to configure xfsprogs with:./configure --sysconfdir=/etc/
To verify what configuration file is used on a system use the typical:
mkfs.xfs -N
There is only a subset of options allowed to be set on the conifiguration file, and currently only 1 or 0 are acceptable values. They are:
[data]
noalign=[inode]
align=
attr=
projid32bit=
sparse=
Quoted 7 lines
Quoted 7 lines
Hey, can I ask a maybe ridiculous question ...
What's the advantage of haggling over ini file parsers and file formats, vs. just:
# echo "-m crc=0 -n ftype=0" > /etc/mkfs.xfs.d/defaultand parse that into defaults exactly as if it had been on the commandline?
Please, no.
A clean, well structure config file is far more important than trying to micro-optimise command line parsing code re-use.
Defaults are not command line parameters - they are what we use when CLI parameters are not specified. Let's not confuse and complicate the issue by causing problems like having to hack around respecification failures because now the CLI parameters respecify parameters in the defaults. Or have to deal with things like specifying a log size default value that is too large for small filesystems, and so mkfs just fails in certain configs. i.e. there are defaults we /don't want/ users to be able to modify....
Quoted 11 lines
Except for having to break that up into individual argv-like strings, I too was wondering if that would be the simplest answer. Same syntax, same parsing of number-with-units, etc.
Should we run getopt ahead of time to pick out the -T arg so that we always load the settings file before we start processing the rest of the cli options? So that:
# mkfs.xfs -m crc=1 -T default /dev/sdaactually formats a v5 fs?
It will already, without any special handling. i.e. The infrastructure I put in place in mkfs for supporting /defaults/ via config files means this isn't a problem we need to care about.
Command line options get parsed into the CLI parameter structure. Defaults are held in a *separate* mkfs_defaults structure. The defaults are only used if the CLI parameters are not specified, but neither are processed until all options and defaults have been parsed into the relevant structures. Hence CLI order does not matter.
IOWs, this problem has already been solved.
Cheers,
Dave.
Signature · 2 lines
Dave Chinner [email protected]