[Ocfs2-devel] [PATCH 3/3] Add inode stealing
for ocfs2_reserve_new_inode.V2
tao.ma
tao.ma at oracle.com
Thu Feb 28 21:17:17 PST 2008
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.
More information about the Ocfs2-devel
mailing list