On Apr 29, 2002 17:23 -0400, Theodore Ts'o wrote: > The only reason why the option is there is because occasionally for > debugging purposes I want to make a filesystem with a smaller number > of blocks in a block group. This is generally bad from a performance > standpoint, but it allows me to create test cases that have a larger > number of block groups without taking up quite as much disk space for > the test filesystem images. That's why it's not documented; the > feature is basically never useful for production filesystems. Actually, if you need to make a very large number of inodes in a filesystem, it is also useful. For example on the LVM initrd image it copies a huge number of /dev entries, but does not have many large files. Also, in my current work, we have a "metadata server" which will hold all of the directory and file/inode information but none of the file data, so it needs way more inodes than data blocks. It is pretty much true that (excluding the journal inode) it will hardly have any data blocks at all, so creating groups only slightly larger than the (maximum sized) inode table is optimal. Cheers, Andreas -- Andreas Dilger http://www-mddsp.enel.ucalgary.ca/People/adilger/ http://sourceforge.net/projects/ext2resize/
