On Fri 03-03-17 21:49:58, 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 ;) ) Yeah, patching sources is IMO more confusing than changing config files. You can at least easily ask for the contents of the config file... Also when analysing XFS issue, you ask for xfs_info output anyway as that is the only way how to be *sure* which features the fs has enabled and mkfs config file does not invalidate that. > 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. Agree with that. Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-xfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
