All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Davidsen <davidsen@tmr.com>
To: raz ben yehuda <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 09:30:58 -0400	[thread overview]
Message-ID: <4A38F012.1070100@tmr.com> (raw)
In-Reply-To: <1245234307.3333.7.camel@raz>

raz ben yehuda wrote:
> On Tue, 2009-06-16 at 19:24 -0400, Bill Davidsen wrote:
>   
>> raz ben yehuda wrote:
>>     
>>> md assumes that personality has all its membes of the same
>>> size,A fact that is incorrect for raid0.
>>>
>>>  md.c |   11 +++++++++--
>>>  1 file changed, 9 insertions(+), 2 deletions(-)
>>>
>>> Signed-off-by: razb <raziebe@gmail.com>
>>> ---
>>> diff --git a/drivers/md/md.c b/drivers/md/md.c
>>> index 0f11fd1..e14fb90 100644
>>> --- a/drivers/md/md.c
>>> +++ b/drivers/md/md.c
>>> @@ -5683,7 +5683,8 @@ static void status_resync(struct seq_file *seq, mddev_t * mddev)
>>>  		max_sectors = mddev->resync_max_sectors;
>>>  	else
>>>  		max_sectors = mddev->dev_sectors;
>>> -
>>> +	if (mddev->level == 0)
>>> +		max_sectors = mddev->resync_max_sectors;
>>>  	/*
>>>  	 * Should not happen.
>>>  	 */
>>> @@ -6280,7 +6281,13 @@ void md_do_sync(mddev_t *mddev)
>>>  			    rdev->recovery_offset < j)
>>>  				j = rdev->recovery_offset;
>>>  	}
>>> -
>>> +	/*
>>> +	* raid0 members may not be of the same size,use array_size.
>>> +	*/
>>> +	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));
>>>   
>>>       
>> If I admit I only spent about 20 minutes looking at this code will you 
>> explain why you use different fields of the struct to set max_sectors? I 
>>     
>
> md_sync uses max_sectors as an ending point of the reshape process.
> problem is that md assumes all raid's members are of the same size, so
> it uses dev_sectors and this is not true to raid0 with multiple zones
>   
>> guess my real confusion is why resync_max_sectors would be valid, given 
>> that raid0 has no redundancy. Or are you using it in some obscure way 
>> for reshape values?  The values stored in the field don't really to be 
>> what you want... Yes, the reshape is new to me.
>>     
> It has nothing to do with redundancy, but with the state machine of md.
> I agree that there should be more elegant way to fix this, but it means
> bigger fixes in md, and this is something I definitely don't want
> to do.
>   

There is always a trade off between cost of implementation and cost of 
maintenance. If Neil is happy with this I have no objection, it just 
seems to invite misunderstanding at some future enhancement. Perhaps a 
an additional comment is desirable, although the name of the field 
invites confusion, pity there's no reshape_* field to use, for 
readability if nothing else.

-- 
Bill Davidsen <davidsen@tmr.com>
  Obscure bug of 2004: BASH BUFFER OVERFLOW - if bash is being run by a
normal user and is setuid root, with the "vi" line edit mode selected,
and the character set is "big5," an off-by-one error occurs during
wildcard (glob) expansion.


  reply	other threads:[~2009-06-17 13:30 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 [this message]
2009-06-17  8:12 ` Andre Noll
2009-06-17  8:23   ` Raz
2009-06-17 16:23     ` Andre Noll
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=4A38F012.1070100@tmr.com \
    --to=davidsen@tmr.com \
    --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.