Andreas Dilger wrote:
Alternately, any inode >= 2^32 would be dynamic? One clear benefit of putting the dynamic inodes at the end of the number space is that they will only be used if the static inodes are full, which reduces risk due to corruption and overhead due to dynamic allocations.
the highest (63th) bit put dynamic inodes at the end, no? the idea is that using 48 bits we can address block directly, w/o any additional lookup via some metainode. essentially this is just a way to introduce 64bit addressable fragments of 2^(64-48-1) size.
* each block is covered by two bits: in inode (I) and block (B) bitmaps: I: 0, B: 0 - block is just free I: 0, B: 1 - block is used, but not contains inodes I: 1, B: 0 - block is full of inodes I: 1, B: 1 - block contains few inodes, has free spaceStoring B:0 for an in-use block seems very dangerous to me. This also doesn't really address the need to be able to quickly locate free inodes, because it means "I:1" _might_ mean the inode is free or it might not, so EVERY "in-use" inode would need to be checked to see if it is free.
just combine I and B into single bitmap: 1) when you look for free block it's any 0 bit in bitmap made by (I & B) 2) when you look for free inode (in current inode blocks) it's any 1 bit in bitmap made again by (I & B), then you read corresponded block and find free slot there (for example, it can be null i_mode) looks very simple and doable?
We need to start with a "dynamic inode bitmap" (DIB) that is mapped from an "inode table file" (possibly only for the dynamic inode table blocks). Free inodes can be scanned using the normal ext4_find_next_zero_bit() in each of the bitmaps.
the idea is that we can implement truly dynamic and varlen inodes w/o introducing special files, using existing structures. thanks, Alex -- 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
