On 3/5/17 7:08 PM, Eric Sandeen wrote: > On 3/3/17 10:56 PM, Dave Chinner wrote: >> On Fri, Mar 03, 2017 at 09:49:58PM -0600, 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 ;) ) >>> >>> 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. >> >> Hence my suggestion of libconfig - it can /write config files/ based >> on the current mkfs config. So there's no need to ship default >> config files - if a user wants a special config they can use mkfs to >> generate it and they can install it appropriately. >> >> e.g. 'mkfs -W <options>' outputs a config file to stdout that >> matches the config specified on the command line, but does not make >> the filesystem (similar to the "-n" option). If no options are >> specified, the default config is emitted.... > > That sounds nice, but I guess I'd like to get some other thoughts > on the overall upsides and downsides of having config files which > alter a bare mkfs.xfs command's behavior. The biggest upside is that we can package up the latest xfsprogs on any distro release and have it work for the user without any surprises. If we do that now, we end up with a mkfs that creates file systems that the kernel can't actually use. The most obvious example is using a modern mkfs.xfs on a system that doesn't support v5 superblocks. There's actually nothing in the man page that will tell a user how to interpret the error message and create a usable file system. Defaults changing over time is good practice, but having a way to keep the old defaults on older systems is useful. Being able to dump the defaults to a file is helpful so that we can check whether the defaults have changed programmatically without having to know about new options ahead of time. That said, by default, we shouldn't install a config file from 'make install.' If distros want to add one, they're welcome to do that either in their xfsprogs package or via some per-release mechanism. -Jeff -- Jeff Mahoney SUSE Labs
Attachment:
signature.asc
Description: OpenPGP digital signature
