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 2/2] ocfs2: Use ocfs2_rec_clusters in ocfs2_adjust_adjacent_records.
Date: Wed, 22 Jul 2009 08:32:32 +0800	[thread overview]
Message-ID: <4A665E20.9040104@oracle.com> (raw)
In-Reply-To: <20090721214051.GC19170@mail.oracle.com>

Joel Becker wrote:
> On Tue, Jul 21, 2009 at 03:42:06PM +0800, Tao Ma wrote:
>   
>> In ocfs2_adjust_adjacent_records, we will adjust adjacent records
>> according to the extent_list in the lower level. But actually
>> the lower level tree will either be a leaf or a branch. So we
>> shouldn't use ocfs2_is_empty_extent which is only valid for a
>> tree leaf. Use ocfs2_rec_clusters instead. We will meet with some
>> problem when the tree depth > 2.
>>     
>
> 	I think you mean "if we leave it as checking e_leaf_clusters,
> we'll have a problem rotating trees with depth > 2".  Is that right?
> Can interior nodes have these empty l_rec[0]s?  If they can't, perhaps
> we should be bugging?
>   
sorry, It should be tree_depth >=2.

ocfs2_adjust_adjacent_records is used to for rotation. And it only use 
e_cpos in most cases.
So we don't have a problem if the lower 16 bits of e_int_clusters isn't 
equal to 0 for a branch.
But if the low 16 bits are 0, this ocfs2_is_empty_extent will treat it 
as an empty record and use the l_recs[1] which will corrupt
the tree. So let me give you a test case I meet.

 Tree Depth: 2   Count: 23   Next Free Rec: 2
        ## Offset        Clusters       Block#
        0  0             9107457        28721
        1  9107457       1922049        28728
Tree Depth: 1   Count: 28   Next Free Rec: 28
        ## Offset        Clusters       Block#
        0  0             227105         28698
        1  227105        197405         28699
   ...
        26 8372225       542208         28725
        27 8914433       193024         28726

Tree Depth: 1   Count: 28   Next Free Rec: 10
        ## Offset        Clusters       Block#
        0  9107457       196608         28727
        1  9304065       204544         28729

In this case: 196608=0x30000, so if we use ocfs2_is_empty_extent will 
treat it as 0, and use 9394065.

Regards,
Tao

  reply	other threads:[~2009-07-22  0:32 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-21  7:35 [Ocfs2-devel] [PATCH 0/2] Two b-tree bug fixes Tao Ma
2009-07-21  7:42 ` [Ocfs2-devel] [PATCH 1/2] ocfs2: Add extra credits and access the modified bh in update_edge_lengths Tao Ma
2009-07-21 21:47   ` Joel Becker
2009-07-21  7:42 ` [Ocfs2-devel] [PATCH 2/2] ocfs2: Use ocfs2_rec_clusters in ocfs2_adjust_adjacent_records Tao Ma
2009-07-21 21:40   ` Joel Becker
2009-07-22  0:32     ` Tao Ma [this message]
2009-07-22  1:13       ` Joel Becker
2009-07-23  0:12         ` [Ocfs2-devel] [PATCH 2/2] ocfs2: Use ocfs2_rec_clusters in ocfs2_adjust_adjacent_records. v2 Tao Ma
2009-07-23 18:10           ` 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=4A665E20.9040104@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.