Re: [RFC] dynamic inodes

[Alex Tomas <bzzz@sun.com>]

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 space
> 
> Storing 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