On Tue, Feb 27, 2018 at 4:45 AM, Theodore Ts'o <tytso@xxxxxxx> wrote: > One other thing I'll mention is that it was really important to me > that it was very easy to look up values from the config file. So for > me it was a lot more than just the parser. So I can fetch a read a > config parameter from the config file like this: > > profile_get_boolean(ctx->profile, "options", "no_optimize_extents", > 0, 0, &c); > > That's because I use this for a lot more than just file system tuning > parametres, but also for changing how e2fsck / mke2fs behaves. So > trying to parse all of the config file at startup time and having to > stash that in some global context structure is just lot of extra work > that isn't necessary with the profile library compared with other > libraries which are focused exclusively on the parsing aspect of > things (which is actually pretty trivial). > > Maybe this doesn't matter for XFS, but other file system utilities may > find this issue to be something worthy of consideration when trying to > pick a config file library. Neat. But yeah, I don't think the nesting would be useful for xfs. Especially as I prefer the /etc/mkfs.xfs.d/ idea. It might make sense to use something like this, instead of foo.bar style prefixing, though. /etc/mkfs.xfs.d/default: [metadata] crc = 0 [naming] ftype = 0 Cheers, Jan > > - Ted > -- > 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 -- 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
