ocfs2-devel.oss.oracle.com archive mirror
 help / color / mirror / Atom feed
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.
> 

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