On 3/7/17 2:07 PM, Jeff Mahoney wrote: > 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. Ok, I'm getting convinced. Thanks for convincing. :) -Eric > 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 >
Attachment:
signature.asc
Description: OpenPGP digital signature
