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 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.