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 3/3] Add inode stealing for	ocfs2_reserve_new_inode.V2
Date: Thu Feb 28 21:17:30 2008	[thread overview]
Message-ID: <47C7955D.8010207@oracle.com> (raw)
In-Reply-To: <20080229014201.GB9349@ca-server1.us.oracle.com>

Mark Fasheh wrote:
> On Fri, Feb 29, 2008 at 09:10:12AM +0800, tao.ma wrote:
>>>> @@ -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.
> 
> Both your points come down to "how do we know when another node has changed
> the allocators such that we can now allocate inodes from our local
> inode_alloc file."
> 
> Unfortunately, we have no way of knowing what another node does. I'm mostly 
> worried about the inefficency of continuously searching ours when there
> isn't likely any room left in it.
> 
> One thing we could do is only go back to our local allocator after some time
> has passed (or some number of allocs). That way we don't check it every
> single time, but we never completely leave it out of the picture either.
OK, so I will modify it. thanks.

      reply	other threads:[~2008-02-28 21:17 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
2008-02-28 17:42       ` Mark Fasheh
2008-02-28 21:17         ` tao.ma [this message]

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=47C7955D.8010207@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.