All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tao Ma <tao.ma@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 0/3] ocfs2: Inode Allocation Strategy Improvement
Date: Fri, 28 Nov 2008 14:49:19 +0800	[thread overview]
Message-ID: <492F946F.1060409@oracle.com> (raw)

Hi all,
	In ocfs2, when we create a fresh file system and create inodes in it, 
they are contiguous and good for readdir+stat. While if we delete all 
the inodes and created again, the new inodes will get spread out and 
that isn't what we need. The core problem here is that the inode block 
search looks for the "emptiest" inode group to allocate from. So if an 
inode alloc file has many equally (or almost equally) empty groups, new 
inodes will tend to get spread out amongst them, which in turn can put 
them all over the disk. This is undesirable because directory operations 
on conceptually "nearby" inodes force a large number of seeks. For more 
details, please see 
http://oss.oracle.com/osswiki/OCFS2/DesignDocs/InodeAllocationStrategy.(I 
have modified it a little, Mark, if you are interested, please look at 
it. They are underlined.)

So this patch set try to fix this problem.
patch 1: Optimize inode allocation by remembering last group.
We add ip_last_used_group in core directory inodes which records
the last used allocation group. Another field named ip_last_used_slot
is also added in case inode stealing happens. When claiming new inode,
we passed in directory's inode so that the allocation can use this
information.

patch 2: let the Inode group allocs use the global bitmap directly.

patch 3: we add osb_last_alloc_group in ocfs2_super to record the last
used allocation group so that we can make inode groups contiguous enough.

The patch set are based on Mark's merge_window, so they are easy to push.

Regards,
Tao

             reply	other threads:[~2008-11-28  6:49 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-28  6:49 Tao Ma [this message]
2008-11-27 22:58 ` [Ocfs2-devel] [PATCH 1/3] ocfs2: Optimize inode allocation by remembering last group Tao Ma
2009-01-06 19:02   ` Mark Fasheh
2009-01-07  0:29     ` Tao Ma
2008-11-27 22:58 ` [Ocfs2-devel] [PATCH 2/3] ocfs2: Allocate inode groups from global_bitmap Tao Ma
2009-01-06 19:47   ` Mark Fasheh
2008-11-27 22:58 ` [Ocfs2-devel] [PATCH 3/3] ocfs2: Optimize inode group allocation by recording last used group Tao Ma
2009-01-06 21:23   ` Mark Fasheh
2009-01-07  0:49     ` Tao Ma
2009-01-07  1:03       ` Mark Fasheh
2009-01-06 21:41 ` [Ocfs2-devel] [PATCH 0/3] ocfs2: Inode Allocation Strategy Improvement Mark Fasheh
2009-01-07  0:27   ` Tao Ma

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=492F946F.1060409@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 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.