All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alex Tomas <bzzz@Sun.COM>
To: ext4 development <linux-ext4@vger.kernel.org>
Subject: [RFC] dynamic inodes
Date: Wed, 24 Sep 2008 15:46:56 +0400	[thread overview]
Message-ID: <48DA28B0.2020207@sun.com> (raw)

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

             reply	other threads:[~2008-09-24 12:04 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-24 11:46 Alex Tomas [this message]
2008-09-25 22:09 ` [RFC] dynamic inodes Andreas Dilger
2008-09-25 23:00   ` Alex Tomas
2008-09-25 23:29     ` Andreas Dilger
2008-09-30 14:02       ` Alex Tomas
2008-09-25 22:37 ` Andreas Dilger
2008-09-26  1:10   ` Jose R. Santos
2008-09-26 10:36     ` Andreas Dilger
2008-09-26 14:49       ` Jose R. Santos
2008-09-26 20:01         ` Andreas Dilger
2008-09-26  2:11   ` Theodore Tso
2008-09-26 10:33     ` Andreas Dilger
2008-09-26 14:33       ` Theodore Tso
2008-09-26 20:18         ` Andreas Dilger
2008-09-26 22:26           ` Theodore Tso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48DA28B0.2020207@sun.com \
    --to=bzzz@sun.com \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.