public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: mingming cao <cmm@us.ibm.com>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Badari Pulavarty <pbadari@us.ibm.com>,
	linux-kernel <linux-kernel@vger.kernel.org>,
	"ext2-devel@lists.sourceforge.net"
	<ext2-devel@lists.sourceforge.net>, Andrew Morton <akpm@osdl.org>
Subject: Re: [Ext2-devel] Ext3 -mm reservations code: is this fix really correct?
Date: 15 Oct 2004 09:01:55 -0700	[thread overview]
Message-ID: <1097856114.4591.28.camel@localhost.localdomain> (raw)
In-Reply-To: <1097846833.1968.88.camel@sisko.scot.redhat.com>

On Fri, 2004-10-15 at 06:27, Stephen C. Tweedie wrote:
> Hi,
> 
> In ext3-reservations-window-allocation-fix.patch from -mm, we try to
> make sure that we always search for a new reservation from the goal
> forwards, not just from the previous window forwards.  I'm assuming this
> is done to optimise random writes.
> 
> I'm still not convinced we get it right.  In alloc_new_reservation(), we
> do:
> 
> 		if ((my_rsv->rsv_start <= group_end_block) &&
> 				(my_rsv->rsv_end > group_end_block))
> 			return -1;
> 
> We get into alloc_new_reservation in the first place either when the
> goal is outside the window, or we could not allocate inside the window.
> 
> Now, in the latter case, the check is correct --- if the window spans
> two block groups and we couldn't allocate in the first block group, then
> we should continue in the next one.
> 
> But what if the goal was in the current block group, but was *prior* to
> the window?  The goal is outside the window, yet the above check may
> still be true, and we'll incorrectly decide to avoid the current block
> group entirely.
> 
> I think we need an "&& start_block >= my_rsv->rsv_start" to deal with
> this.
> 

You are right. I think at the beginning we were decide the honor the the
reservation window if the goal is out of the window. Considering the
goal is selected with good reason, we agreed that we should try honor
the goal block all the time.But we missed this case apparently.

> If we get past that test --- the reservation window is all entirely
> inside one group --- then we have the following chunk in
> xt3-reservations-window-allocation-fix.patch:
> 
> -		/* remember where we are before we discard the old one */
> -		if (my_rsv->rsv_end + 1 > start_block)
> -			start_block = my_rsv->rsv_end + 1;
> -		search_head = my_rsv;
> +		search_head = search_reserve_window(&my_rsv->rsv_node, start_block);
> 
> which I'm assuming is trying to pin the search start to the goal block. 
> But that's wrong --- search_reserve_window does a downwards-traversing
> tree search, and needs to be given the root of the tree in order to find
> a given block.  Giving it the current reservation node as the search
> start point is not going to allow it to find the right node in all
> cases.
> 
> Have I misunderstood something?
> 
You are correct, again:) We should do a search_reserve_window() from the
root.

I will post a fix for these two soon.

Mingming


  reply	other threads:[~2004-10-15 16:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-15 13:27 Ext3 -mm reservations code: is this fix really correct? Stephen C. Tweedie
2004-10-15 16:01 ` mingming cao [this message]
2004-10-15 16:40   ` [Ext2-devel] " Stephen C. Tweedie
2004-10-15 20:29     ` mingming cao
2004-10-15 22:20       ` Stephen C. Tweedie
2004-10-15 22:34         ` mingming cao
2004-10-18 22:55           ` [PATCH 2/3] ext3 reservation allow turn off for specifed file Mingming Cao
2004-10-18 23:42             ` Andrew Morton
2004-10-19  1:01               ` Mingming Cao
2004-10-20 17:55                 ` Ray Lee
2004-10-25 20:33                   ` [Ext2-devel] " Mingming Cao
2004-10-25 23:05                     ` Mingming Cao
2004-10-25 23:45                       ` Andrew Morton
2004-10-26 16:53                         ` Mingming Cao
2004-10-26 20:18                           ` Andrew Morton
2004-10-26 23:01                             ` Mingming Cao

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=1097856114.4591.28.camel@localhost.localdomain \
    --to=cmm@us.ibm.com \
    --cc=akpm@osdl.org \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pbadari@us.ibm.com \
    --cc=sct@redhat.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