From: Tao Ma <tao.ma@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [RFC] metadata alloc fix in machines which has PAGE_SIZE > CLUSTER_SIZE
Date: Fri, 20 Mar 2009 08:41:28 +0800 [thread overview]
Message-ID: <49C2E638.4090109@oracle.com> (raw)
In-Reply-To: <20090320003022.GC13065@wotan.suse.de>
Hi Mark,
Mark Fasheh wrote:
>> So my thought is that can we reuse the freed extent block? I guess we
>> can. We just need to store the pointer of ocfs2_cached_dealloc_ctxt in
>> ocfs2_alloc_context. So whenever we allocate a new metadata, we try to
>> search ocfs2_cached_dealloc_ctxt first, if there is some, we use it
>> directly and delete it from ocfs2_cached_dealloc_ctxt. The same can go
>> for cluster allocation I guess although I don't know whether we have
>> such case for clusters.
>>
>> make sense?
>
> Yes, but I think a better approach is to fix the core problem, instead of
> working around it. What we want to do then is make ocfs2_lock_allocators
> smart enough to catch this case so that it can reserve the proper amount of
> meta data. The good news is that we already do a scan of the writeable area
> in ocfs2_populate_write_desc(). It seems to me that scan is a good place
> where we could store some information about contiguous extents which will be
> merged. The only thing that'd be left for ocfs2_lock_allocators to do is
> look at the remaining extent block counts.
actually this bug is found in reflink implementations. And in that case,
it is more complicated. Since we are CoW at most 1M bytes in one
transaction, that means 256 clusters at most, so we will have a very
great chance to meet with many steps like this. And my simple test case
has met with 6 (delete and add) for just one CoW. So I don't think we
can make ocfs2_lock_allocators that smart enough to overcome it.
And if you look at my patch sent yesterday afternoon, it is very
straightforward, and it only begin to work in the old BUG_ON scenario.
So I think it is acceptable.
Regards,
Tao
prev parent reply other threads:[~2009-03-20 0:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-18 13:57 [Ocfs2-devel] [RFC] metadata alloc fix in machines which has PAGE_SIZE > CLUSTER_SIZE Tao Ma
2009-03-18 22:26 ` [Ocfs2-devel] [PATCH] ocfs2: Reused freed extent block in b-tree operation Tao Ma
2009-03-19 22:13 ` Joel Becker
2009-03-20 0:30 ` [Ocfs2-devel] [RFC] metadata alloc fix in machines which has PAGE_SIZE > CLUSTER_SIZE Mark Fasheh
2009-03-20 0:41 ` 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=49C2E638.4090109@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.