From: Tao Ma <tao.ma@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [patch 0/2] Add inode steal in ocfs2-1.2
Date: Wed, 30 Apr 2008 15:18:19 +0800 [thread overview]
Message-ID: <48181D3B.3070503@oracle.com> (raw)
In-Reply-To: <20080430070805.GA11248@dhcp-beijing-cdc-10-182-121-54.cn.oracle .com>
One more thing, it has been tested with my script which has been sent to
ocfs2-tools-devel for review. Please see
http://oss.oracle.com/pipermail/ocfs2-tools-devel/2008-March/000621.html
Regards,
Tao
tao.ma at oracle.com wrote:
> Hi all,
> This patch series add inode steal mechanism for inode allocation and
> it is backported from 2.6.26.
>
> In OCFS2, we allocate the inodes from slot specific inode_alloc to avoid
> inode creation congestion. The local alloc file grows in a large contiguous
> chunk. As for a 4K bs, it grows 4M every time. So 1024 inodes will be
> allocated at a time.
>
> Over time, if the fs gets fragmented enough(e.g, the user has created
> many small files and also delete some of them), we can end up in a situation,
> whereby we cannot extend the inode_alloc as we don't have a large chunk
> free in the global_bitmap even if df shows few gigs free. More annoying
> is that this situation will invariably mean that while one cannot create
> inodes on one node but can from another node. Still more annoying is that an
> unused slot may have space for plenty of inodes but is unusable as the user may
> not be mounting as many nodes anymore.
>
> This patch series implement a solution which is to steal inodes from
> another slot. Now the whole inode allocation process looks like this:
> 1. Allocate from its own inode_alloc:000X
> 1) If we can reserve, OK.
> 2) If fails, try to allocate a large chunk and reserve once again.
> 2. If 1 fails, try to allocate from the ocfs2_super->inode_steal_slot.
> This time, Just try to reserve, we don't go for global_bitmap if
> this inode also can't allocate the inode.
> 3. If 2 fails, try the node next until we reach that steal slot again.
>
> ocfs2_super->inode_steal_slot is initalized as the node next to our own
> slot. And once the inode stealing successes, we will refresh it with
> the slot we steal inode from. It will also be reinitalized when the
> local truncate log or local alloc recovery is flushed in which case the global
> bitmap may be refreshed.
>
next parent reply other threads:[~2008-04-30 7:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080430070805.GA11248@dhcp-beijing-cdc-10-182-121-54.cn.oracle.com>
2008-04-30 7:18 ` Tao Ma [this message]
2008-04-30 17:13 ` [Ocfs2-devel] [patch 0/2] Add inode steal in ocfs2-1.2 Sunil Mushran
2008-05-02 7:48 ` Tao Ma
2008-04-30 7:08 tao.ma at oracle.com
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=48181D3B.3070503@oracle.com \
--to=tao.ma@oracle.com \
--cc=ocfs2-devel@oss.oracle.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).