All of lore.kernel.org
 help / color / mirror / Atom feed
* [Ocfs2-devel] [PATCH 0/3] Add inode steal for ocfs2.V2
@ 2008-02-27 22:36 Tao Ma
  2008-02-27 22:59 ` [Ocfs2-devel] [PATCH 1/3] Add a new parameter for ocfs2_reserve_suballoc_bits.V2 Tao Ma
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Tao Ma @ 2008-02-27 22:36 UTC (permalink / raw)
  To: ocfs2-devel

Hi all,
This patch series add inode steal mechanism for inode allocation.

Modification from V1 to V2:
1. Add a new member in ocfs2_super which will record the slot we steal
   the inode successfully. This will speed up the next steal.
2. Modify the mechanism of inode stealing. Now we will start our search
   from the node next to it. 
3. Remove the last and extra inode allocation in the local slot since
   there is no evidence that we will have our global bitmap be emptied
   enough in the time it takes us to search the other allocators.

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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2008-02-28 21:17 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-27 22:36 [Ocfs2-devel] [PATCH 0/3] Add inode steal for ocfs2.V2 Tao Ma
2008-02-27 22:59 ` [Ocfs2-devel] [PATCH 1/3] Add a new parameter for ocfs2_reserve_suballoc_bits.V2 Tao Ma
2008-02-28 15:06   ` Mark Fasheh
2008-02-27 23:01 ` [Ocfs2-devel] [PATCH 2/3] Add ac_alloc_slot in ocfs2_alloc_context.V2 Tao Ma
2008-02-28 15:08   ` Mark Fasheh
2008-02-27 23:01 ` [Ocfs2-devel] [PATCH 3/3] Add inode stealing for ocfs2_reserve_new_inode.V2 Tao Ma
2008-02-28 15:31   ` Mark Fasheh
2008-02-28 17:11     ` tao.ma
2008-02-28 17:42       ` Mark Fasheh
2008-02-28 21:17         ` tao.ma

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.