linux-ext4 - [RFC] dynamic inodes

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-id: <48DA28B0.2020207@sun.com>
Date:	Wed, 24 Sep 2008 15:46:56 +0400
From:	Alex Tomas <bzzz@....COM>
To:	ext4 development <linux-ext4@...r.kernel.org>
Subject: [RFC] dynamic inodes

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html