Hi,
another idea how to achieve more (dynamic) inodes:
* new dir_entry format with 64bit inum
* ino space is 64bit:
* 2^48 phys. 4K blocks
* 2^5 inodes in 4K block
* highest bit is used to choose addressing schema: static or dynamic
* 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
implementation issues:
* how to allocate new blocks for inodes
* try to find block with empty inode using bitmaps
* if we can't find - allocate new block and make it inode block
* if no free block in this group - repeat 1-2 in another groups
* how to release block from inodes
* if block has no used inodes anymore, we mark it 0 in I and 1 in B
* or if group has very few free inodes, leave it inode block
* how to find free inode in existing inode block
* just scan all slots
* how to migrate/co-exist with static inodes
* group is marked with DYNAMIC_INODES flag
* we can turn group to dynamic when it has 0 inodes (simple)
* we can turn group to dynamic and update bitmaps (hard)
* how to implement varlen inodes
* should be simple at allocation time
possibilities:
* use large inodes to store directory entries
(4096-128)/(4+8+8) = 198 entries
* use large inodes to store EAs
* if we introduce small header for new inode block we could use it to store tails
problems:
* can't relocate inode w/o changing directory entry
* can't change inode size after creation
* e2fsck?
comments/suggestions are very welcome.
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
