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
next 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.