All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre Noll <maan@systemlinux.org>
To: Raz <raziebe@gmail.com>
Cc: linux raid <linux-raid@vger.kernel.org>, Neil Brown <neilb@suse.de>
Subject: Re: Subject:[PATCH 001:013]: md: Raid0 reshape
Date: Wed, 17 Jun 2009 18:23:27 +0200	[thread overview]
Message-ID: <20090617162327.GC6403@skl-net.de> (raw)
In-Reply-To: <5d96567b0906170123q2fad427bu37526f3692b0f0f6@mail.gmail.com>

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

On 11:23, Raz wrote:

> >> +     if (mddev->level == 0) {
> >> +             max_sectors = mddev->array_sectors;
> >> +             j = mddev->recovery_cp;
> >> +     }
> >>       printk(KERN_INFO "md: %s of RAID array %s\n", desc, mdname(mddev));
> >>       printk(KERN_INFO "md: minimum _guaranteed_  speed:"
> >>               " %d KB/sec/disk.\n", speed_min(mddev));
> >
> > Hm, we want to get rid of personality-dependent code in md.c, so new
> > code should never check mddev->level. In the first hunk I think it
> > would be possible to check if pers->sync_request is NULL.
> No. sync_request does exists. this is what Neil wanted me to do.
> implement raid0_sync
> so I will be using md for this purpose. I knew that md patch is a
> problem, this is why I posted
> it first.

OK, so pers->sync_request can't be used, but that was only one
possible option to replace the check mddev->level == 0 by something
more generic. BTW: The log message should describe in which case the
resync status shows an incorrect value and why one can not determine
which value to use for max_sectors by looking at mddev->recovery.

> > Is the second hunk really necessary? AFAICS md_do_sync() won't be
> > called for raid0 anyway.
> second hunk is necessary for resume reshape. md_do_sync is called
> indirecrly by raid0d -->md_check_recovery.

Yes, I didn't notice because raid0d() is introduced later in patch
10/13 of your series. When introducing new and apparently dead code
it's always nice to let people know that the new code is going to be
used by a function that will be added in a subsequent patch :)

Regards
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-06-17 16:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-16 21:51 Subject:[PATCH 001:013]: md: Raid0 reshape raz ben yehuda
2009-06-16 23:24 ` Bill Davidsen
2009-06-17 10:25   ` raz ben yehuda
2009-06-17 13:30     ` Bill Davidsen
2009-06-17  8:12 ` Andre Noll
2009-06-17  8:23   ` Raz
2009-06-17 16:23     ` Andre Noll [this message]
2009-06-18 11:42       ` Raz

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=20090617162327.GC6403@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 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.