Al writes:> > I had always assumed that it would be a power-of-two size, but since it> > is an undocumented option to mke2fs, I suppose it was never really> > intended to be used. It appears, however, that the mke2fs code> > doesn't do ANY checking on the parameter, so you could concievably make> > the inode size SMALLER than the current size, and this would DEFINITELY> > be bad as well.> > In some sense it does - it dies if you've passed it not a power of two ;-)> I don't think that segfault is a good way to report the problem, though...

Strange, I run "mke2fs -I 192 /dev/hdc2" and do not have a segfault or anyproblems with e2fsck or debugfs on the resulting filesystem. I'm running1.20-WIP, but I don't think anything was changed in this area for some time.

However, looking at the output from dumpe2fs shows it is packing inodesacross block boundaries (inode_size = 192, inodes_per_group = 16144,inode_blocks_per_group = 757). It is also not filling the last inodetable block (which would give us 16149 inodes).

Also, looking at the disk, it shows garbage data in the space after theend of the normal inode, and ext2 should always zero-fill unused fields.

Basically, packing inodes across block boundaries is TOTALLY broken.This can lead to all sorts of data corruption issues if one block iswritten to disk, and the other is not. For that matter, the same wouldhold true with any not-power-of-two inode size. In this case, theinode will still be crossing a hard disk sector boundary, and have the(small) possibility that part of the inode is written and part is not.

In this light, the safe inode sizes are 128 (current size), 256, and 512.

> > mke2fs will always set up the filesystem this way, and there is no real> > reason NOT to do that. If you are using a filesystem block for the inode> > table, it is pointless to leave part of it empty, because you can't use> > it for anything else anyways.> > It's not that simple - if you need 160 bytes per inode rounding it up> to the next power of two will lose a lot. On 4Kb fs it will be> 16 inodes per block instead of 25 - 36% loss...

What I was getting at, is that no matter what size of inode we are using,we should ALWAYS fill the last inode table block as full as possible. Onceyou have allocated a block to the inode table, it should be filled withas many inodes as fit in a single block. To do anything else is a waste.

For example, with 160 byte inodes, and a 4k inode table block, we can fit

4096 / 160 = 25 inodes into this block (with 96 bytes remaining)

There is no reason to only have 1 or 2 or 17 inodes in this block. If weassume we are not crossing a block boundary with the inode, theninodes_per_group = n * inodes_per_block, where n = number of inode blocks.