From: tao.ma <tao.ma@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH 3/3] Add inode stealing for ocfs2_reserve_new_inode.V2
Date: Thu Feb 28 17:11:41 2008 [thread overview]
Message-ID: <47C75B74.2090009@oracle.com> (raw)
In-Reply-To: <20080228233042.GW27865@ca-server1.us.oracle.com>
Mark Fasheh wrote:
> On Thu, Feb 28, 2008 at 03:00:26PM +0800, tao.ma wrote:
>> Add inode stealing for ocfs2_reserve_new_inode. Now the whole process is:
>> 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.
>
> How about when we free an inode from our slots allocator?
As I always start to allocate from my own slot first, so this should not
be a problem since if we free an inode, this block can be allocated
again to the new request.
>> int ocfs2_reserve_new_inode(struct ocfs2_super *osb,
>> struct ocfs2_alloc_context **ac)
>> {
>> @@ -542,6 +577,17 @@ int ocfs2_reserve_new_inode(struct ocfs2_super *osb,
>> status = ocfs2_reserve_suballoc_bits(osb, *ac,
>> INODE_ALLOC_SYSTEM_INODE,
>> osb->slot_num, ALLOC_NEW_GROUP);
>> + if (status >= 0) {
>> + status = 0;
>> + goto bail;
>> + } else if (status < 0 && status != -ENOSPC) {
>> + mlog_errno(status);
>> + goto bail;
>> + }
>> +
>> + ocfs2_free_ac_resource(*ac);
>> +
>> + status = ocfs2_steal_inode_from_other_nodes(osb, *ac);
>
> Does this mean we always search our own first, even if we know it's not
> likely to have anything in it? Wouldn't it be better to ignore once it's
> full until we get to one of the spots where you've inserted a call to
> ocfs2_init_inode_steal_slot)?
I am worried about the situation that the global bitmap is flushed by
other nodes and how the current node notice this and use its own local
allocator again. Or should it notice this?
Another thing is that what if the inode which is owned by this slot
deleted by other slots? We should have the ability to allocate the inode
from our own slot now.
next prev parent reply other threads:[~2008-02-28 17:11 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2008-02-28 17:42 ` Mark Fasheh
2008-02-28 21:17 ` 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=47C75B74.2090009@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.