linux-raid.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andre Noll <maan@systemlinux.org>
To: NeilBrown <neilb@suse.de>
Cc: raziebe@gmail.com, linux-raid@vger.kernel.org
Subject: Re: [PATCH] md: raid0: Replace hash table lookup by looping over all strip_zones.
Date: Thu, 14 May 2009 14:10:42 +0200	[thread overview]
Message-ID: <20090514121042.GH11504@skl-net.de> (raw)
In-Reply-To: <fe4d072c76f1ce1d6b2b75f83766b1f0.squirrel@neil.brown.name>

[-- Attachment #1: Type: text/plain, Size: 2399 bytes --]

On 21:15, NeilBrown wrote:
> > +/* Find the zone which holds a particular offset */
> > +static struct strip_zone *find_zone(struct raid0_private_data *conf,
> > +		sector_t sector)
> > +{
> > +	int i;
> > +
> > +	for (i = 0; i < conf->nr_strip_zones; i++) {
> > +		struct strip_zone *z = conf->strip_zone + i;
> > +
> > +		if (sector < z->zone_start + z->sectors)
> > +			return z;
> > +	}
> 
> Maybe I'm being petty, but I really don't like this...
> 
> I really like
> > -        while (sector >= zone->zone_start + zone->sectors)
> > -                zone++;
> 
> It seems to capture what is really happening.
> But I can see that your code has a defensive aspect to it
> which is hard to argue against.
> 
> It's probably the fact that there are two loop variables (i and z)
> that bothers me....
> Here is a thought.  How about we extend the stripe_zone array
> by one element and put a sentinal at the end, with ->zone_start being
> the size of the drive ... or maybe even "max sector".
> 
> Then the loop could be
>    for (i = 0; i < conf->nr_strip_zones; i++)
>          if (sector < conf->strip_zone[i+1])
>                return conf->strip_zone[i]
> 
> Save our selves an 'add' that way :-)

Saving an addition is a good thing as find_zone() is certainly
performance-critical. After all, that's why the original author used
hash tables.

The drawback is of course that we will happily return the last zone
for (invalid) requests beyond the array size. If that happens, data
corruption on the drive(s) of the last zone will likely be the result,
so I feel a bit uncomfortable in doing this.

How about extending stripe_zone as you propose, storing the array
size in ->zone_start of the last element and still call BUG() after
the loop?  That still saves the additional add and avoids the mentioned
data corruption.

> > +	zone = find_zone(conf, sector);
> > +	if (!zone)
> > +		return 1;
> 
> I don't much like those last two lines either.  zone will
> never be NULL because if find_zone doesn't find anything, it
> calls BUG.  And returning from make_request without doing any IO
> is just wrong.  So those two lines can go.

Yup. Do you want me to rework the patches, or should I follow up with
patches on top of the series?

Thanks
Andre
-- 
The only person who always got his work done by Friday was Robinson Crusoe

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

  reply	other threads:[~2009-05-14 12:10 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-14 10:43 [PATCH 0/6] md: Remove the hash tables from raid0 Andre Noll
2009-05-14 10:43 ` [PATCH] md: raid0: Replace hash table lookup by looping over all strip_zones Andre Noll
2009-05-14 11:15   ` NeilBrown
2009-05-14 12:10     ` Andre Noll [this message]
2009-05-14 12:25       ` NeilBrown
2009-05-14 12:54         ` Sujit Karataparambil
2009-05-14 15:00           ` SandeepKsinha
2009-05-14 15:58         ` PATCH md [001:002]: raid0: fix chunk size to 4K*n granularity raz ben yehuda
2009-05-14 14:07           ` Andre Noll
2009-05-14 22:35           ` Neil Brown
2009-05-18 22:58             ` raz ben yehuda
2009-05-14 16:00         ` Subject: PATCH[002:002] md: raid0: dump raid configuration raz ben yehuda
2009-05-14 17:12         ` Subject: [PATCH] mdadm: raid0: support chunks of 4K*n for raid0 raz ben yehuda
2009-05-15  3:59           ` Sujit Karataparambil
2009-05-15  6:01             ` Raz
2009-05-15  6:45               ` Sujit Karataparambil
2009-05-15  8:39                 ` NeilBrown
2009-05-15 15:45                   ` Raz
2009-05-14 12:22     ` [PATCH] md: raid0: Replace hash table lookup by looping over all strip_zones Neil Brown
2009-05-14 15:51       ` raz ben yehuda
2009-05-14 20:38         ` NeilBrown
2009-05-15 13:18           ` Andre Noll
2009-05-15 17:30         ` Andre Noll
2009-05-15 21:19           ` Raz
2009-05-18  8:21             ` Andre Noll
2009-05-14 11:15   ` SandeepKsinha
2009-05-14 12:01   ` SandeepKsinha
2009-05-14 12:15     ` SandeepKsinha
2009-05-14 14:13   ` raz ben yehuda
2009-05-14 10:43 ` [PATCH] md: raid0: Remove hash table Andre Noll
2009-05-14 10:43 ` [PATCH] md: raid0: Remove hash spacing and sector shift Andre Noll
2009-05-14 10:43 ` [PATCH] md: raid0: Make raid0_run() return a proper error code Andre Noll
2009-05-14 11:21   ` NeilBrown
2009-05-14 11:42     ` Andre Noll
2009-05-14 10:43 ` [PATCH] md: raid0: Kfree() strip_zone and devlist in create_strip_zones() Andre Noll
2009-05-14 10:43 ` [PATCH] md: raid0: Simplify raid0_run() Andre Noll
2009-05-14 11:43   ` SandeepKsinha
2009-05-14 12:06     ` NeilBrown
2009-05-14 14:03   ` raz ben yehuda

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=20090514121042.GH11504@skl-net.de \
    --to=maan@systemlinux.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=neilb@suse.de \
    --cc=raziebe@gmail.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).