On Mon, May 07, 2007 at 11:31:22AM -0500, Eric Sandeen wrote: One of > our testers filed a bug that said "mkfs.ext3 is much slower when > mke2fs.conf is missing..." > > This is because the shipped defaults in mke2fs.conf do not match the > shipped defaults in the mkfs code itself; he wound up making a 1k > block filesystem on a very large block device, for example. > > So - How about this patch, to bring them back into line? It doesn't actually bring them completely back into line, since mke2fs will use different block sizes depending on the size of the filesystem. So your patch makes the default probably a bit more reasonable, and so I'll probably end up applying it, but it definitely isn't a complete replacement for /etc/mke2fs.conf. How likely do you think the case will be that mke2fs.conf would be missing? I'm trying to figure out how high priority of an item this really is. > Which makes me wonder; having "defaults" in 2 different places is > bound to get out of sync; should we instead generate both code & > config file defaults (and maybe man page defaults) from a common > source? I had been working on the assumption that the defaults if mke2fs.conf were not present were more in the nature of emergency defaults as opposed something that could be used a fully functional set of configuration parameters. So the assumption was that when you installed the RPM, mke2fs.conf would also be there. We could enhance the profile code so that it could read in the profile from a memory buffer, and simply compile /etc/mke2fs.conf into mke2fs, but that adds bloat --- the question is how necessary do we think that really is? Regards, - Ted - To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
