From: Tao Ma <tao.ma@oracle.com>
To: ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [RFC] ocfs2: Make ocfs2_extend_trans really extending.
Date: Thu, 08 Apr 2010 07:43:20 +0800 [thread overview]
Message-ID: <4BBD1898.1010308@oracle.com> (raw)
In-Reply-To: <20100407215316.GQ11402@wotan.suse.de>
Hi Mark,
Mark Fasheh wrote:
> On Mon, Mar 22, 2010 at 04:01:44PM +0800, Tao Ma wrote:
>
>> Hi Joel/Mark/Sunil,
>> This patch just want to make ocfs2_extend_trans(which used
>> to restart the journal with only 'nblocks' in some case) really
>> extending. I have met with many troubles when I used this function
>> in implementing xattr support. And I used to think that it is
>> my fault.
>>
>> But I changed my mind when I saw that Joel(Sorry, Joel, ;) ) also use
>> it wrongly. See
>> http://git.kernel.org/?p=linux/kernel/git/jlbec/ocfs2.git;a=commitdiff;h=991f171d287781ae12d1ec06cb1917dae3334a9b;hp=f5abd5404e8d1551f1bf58b711543e3b5dcc1079
>>
>> Acutally ocfs2_extend_trans in ocfs2_block_group_alloc_discontig
>> has to be
>> status = ocfs2_extend_trans(handle,
>> ocfs2_calc_bg_discontig_credits(osb->sb) +
>> handle->h_buffer_credits);
>> because we will modify the bitmap file later which isn't included in
>> ocfs2_calc_bg_discontig_credits.
>>
>> That makes me to think more. So why we don't reserve the old blocks? I just
>> skimmed all the callers of ocfs2_extend_trans, and to my surprise, 12 of 15
>> callers added h_buffer_credits by themself to avoid the problem. Then why
>> handle this in ocfs2_extend_trans? So here comes the patch. Please review.
>>
>
> Tao, this patch looks good to me. Thank you for taking on the time to fix up
> this old interface. Have you tested the patch much? What are the results
> like? Not only in stability, but does the new math inside
> ocfs2_extend_trans() speed up any long-running operations?
>
I only did tristan's reflink test cases. And since it is only a RFC, I
haven't put much time on it.
If you and Joel are both fine with it, I will give it more try,
especially the stress test case on xattr, since it depends on
it heavily. And also I will run some fill_verify_hole test which will
stress our b-tree codes.
I think these 2 places may be impacted most by this patch.
Regards,
Tao
next prev parent reply other threads:[~2010-04-07 23:43 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 8:01 [Ocfs2-devel] [RFC] ocfs2: Make ocfs2_extend_trans really extending Tao Ma
2010-04-07 21:53 ` Mark Fasheh
2010-04-07 23:43 ` Tao Ma [this message]
2010-04-07 23:54 ` Joel Becker
2010-04-21 3:29 ` Tao Ma
2010-04-23 20:45 ` Joel Becker
2010-04-26 6:34 ` [Ocfs2-devel] [PATCH] " Tao Ma
2010-04-26 6:54 ` Joel Becker
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=4BBD1898.1010308@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).