man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[Igor Podlesny]

	"... It can also be used when creating a RAID1 or RAID10 if you want
to avoid  the  initial  resync ..."
	
	I'm wondering why namely those levels are chosen and not RAID5/6 for e. g.?
	
	I think it's also safe to use with RAID5/6, isn't it?

-- 
End of message. Next message?

Re: man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[Drew]

>        "... It can also be used when creating a RAID1 or RAID10 if you want
> to avoid  the  initial  resync ..."
>
>        I'm wondering why namely those levels are chosen and not RAID5/6 for e. g.?
>
>        I think it's also safe to use with RAID5/6, isn't it?

RAID1/10 don't have parity calculations whereas RAID5/6 do.

-- 
Drew

"Nothing in life is to be feared. It is only to be understood."
--Marie Curie
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[Igor Podlesny]

2009/8/23 Drew <drew.kay@gmail.com>:
>>        "... It can also be used when creating a RAID1 or RAID10 if you want
>> to avoid  the  initial  resync ..."
>>
>>        I'm wondering why namely those levels are chosen and not RAID5/6 for e. g.?
>>
>>        I think it's also safe to use with RAID5/6, isn't it?
>
> RAID1/10 don't have parity calculations whereas RAID5/6 do.

	Well, and what does it change? I mean if we write some data to that
"assume clean" RAID5/6 the parity will be updated anyway.

-- 
End of message. Next message?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[NeilBrown]

On Sun, August 23, 2009 3:48 am, Igor Podlesny wrote:
> 2009/8/23 Drew <drew.kay@gmail.com>:
>>>        "... It can also be used when creating a RAID1 or RAID10 if
>>> you want
>>> to avoid  the  initial  resync ..."
>>>
>>>        I'm wondering why namely those levels are chosen and not
>>> RAID5/6 for e. g.?
>>>
>>>        I think it's also safe to use with RAID5/6, isn't it?
>>
>> RAID1/10 don't have parity calculations whereas RAID5/6 do.
>
> 	Well, and what does it change? I mean if we write some data to that
> "assume clean" RAID5/6 the parity will be updated anyway.
>

Yes it will be updated.  But if it is updated with a
read-modify-write cycle then an old incorrect value will be updated
to a new incorrect value, which doesn't help you much.

The current RAID6 implementation never does read-modify-write for
P/Q update so you could get away with --assume-clean there, but I
don't promise that future implementations will never use r-m-w.
RAID5 definitely does use R-M-W for single-block writes on
arrays of 4 or more drives.

NeilBrown

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[Igor Podlesny]

2009/8/23 NeilBrown <neilb@suse.de>:
[...]
> Yes it will be updated.  But if it is updated with a
> read-modify-write cycle then an old incorrect value will be updated
> to a new incorrect value, which doesn't help you much.

	I see. Thank you for the answer. My assumption was due thinking that
parity is never being used when RAID5 is in "healthy" mode.
	
	But anyway, please clear it up: if I've made --asume-clean RAID5
array, formatted it with some FS (or even LVM), and put OS/data to it,
then (in idle at night, for e. g.) run "resync", would that be the
same valid result (overall data integrity) as if I had previously
created it without "--asume-clean" at all? (Let's suppose hard disks
were healthy in both cases :-)

	And Neil, using the chance to have your reply :-) I'd like to ask one
more question: is that true (I think and hope it is!) that MD doesn't
read/write full chunk size when it's just to read/write another block
of data and hence chunk size only affects data interleaving on disks.
	
	P. S. Is there someone on this list who can share his linux-RAID
archive in mbox format? From time to time I find interesting
discussions have been going but can't just hit "Reply". If you can
help me with that, please reply personally (not CC:ing to the list).
Thanks!

-- 
End of message. Next message?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[Neil Brown]

On Sunday August 23, for.poige+linux@gmail.com wrote:
> 2009/8/23 NeilBrown <neilb@suse.de>:
> [...]
> > Yes it will be updated.  But if it is updated with a
> > read-modify-write cycle then an old incorrect value will be updated
> > to a new incorrect value, which doesn't help you much.
> 
> 	I see. Thank you for the answer. My assumption was due thinking that
> parity is never being used when RAID5 is in "healthy" mode.
> 	
> 	But anyway, please clear it up: if I've made --asume-clean RAID5
> array, formatted it with some FS (or even LVM), and put OS/data to it,
> then (in idle at night, for e. g.) run "resync", would that be the
> same valid result (overall data integrity) as if I had previously
> created it without "--asume-clean" at all? (Let's suppose hard disks
> were healthy in both cases :-)

If by 'run "resync"' you mean
   echo repair > /sys/block/mdXX/md/sync_action
then yes, what will have the same effect as not using --assume-clean
to start with.

> 
> 	And Neil, using the chance to have your reply :-) I'd like to ask one
> more question: is that true (I think and hope it is!) that MD doesn't
> read/write full chunk size when it's just to read/write another block
> of data and hence chunk size only affects data interleaving on disks.

That is correct - chunk size only affect data layout, not IO size.
md/raid5 always reads or writes a whole page (normally 4K) at a time.

NeilBrown


> 	
> 	P. S. Is there someone on this list who can share his linux-RAID
> archive in mbox format? From time to time I find interesting
> discussions have been going but can't just hit "Reply". If you can
> help me with that, please reply personally (not CC:ing to the list).
> Thanks!
> 
> -- 
> End of message. Next message?
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[CoolCold]

On Wed, Aug 26, 2009 at 2:25 AM, Neil Brown <neilb@suse.de> wrote:
>
> On Sunday August 23, for.poige+linux@gmail.com wrote:
> > 2009/8/23 NeilBrown <neilb@suse.de>:
> > [...]
> > > Yes it will be updated.  But if it is updated with a
> > > read-modify-write cycle then an old incorrect value will be updated
> > > to a new incorrect value, which doesn't help you much.
> >
> >       I see. Thank you for the answer. My assumption was due thinking that
> > parity is never being used when RAID5 is in "healthy" mode.
> >
> >       But anyway, please clear it up: if I've made --asume-clean RAID5
> > array, formatted it with some FS (or even LVM), and put OS/data to it,
> > then (in idle at night, for e. g.) run "resync", would that be the
> > same valid result (overall data integrity) as if I had previously
> > created it without "--asume-clean" at all? (Let's suppose hard disks
> > were healthy in both cases :-)
>
> If by 'run "resync"' you mean
>   echo repair > /sys/block/mdXX/md/sync_action
> then yes, what will have the same effect as not using --assume-clean
> to start with.
>
> >
> >       And Neil, using the chance to have your reply :-) I'd like to ask one
> > more question: is that true (I think and hope it is!) that MD doesn't
> > read/write full chunk size when it's just to read/write another block
> > of data and hence chunk size only affects data interleaving on disks.
>
> That is correct - chunk size only affect data layout, not IO size.
> md/raid5 always reads or writes a whole page (normally 4K) at a time.
>
> NeilBrown
>
>

Hmm...so how read from some program -> fs -> md happens then? I.e. -
if FS has stride/stripe/swidth for, say, 64kb (and md chunk size is
64kb), some program requests 128kb of data to be read, does it mean
we'll do 16 reads for 4kb from two drives? Even if we do, is it
right/good ?


--
Best regards,
[COOLCOLD-RIPN]
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: man mdadm regarding --assume-clean says it's OK to use with RAID1 or 10, when creating:

[NeilBrown]

On Wed, August 26, 2009 9:34 am, CoolCold wrote:
> On Wed, Aug 26, 2009 at 2:25 AM, Neil Brown <neilb@suse.de> wrote:
>>
>> On Sunday August 23, for.poige+linux@gmail.com wrote:
>> > 2009/8/23 NeilBrown <neilb@suse.de>:
>>
>> That is correct - chunk size only affect data layout, not IO size.
>> md/raid5 always reads or writes a whole page (normally 4K) at a time.
>>
>> NeilBrown
>>
>>
>
> Hmm...so how read from some program -> fs -> md happens then? I.e. -
> if FS has stride/stripe/swidth for, say, 64kb (and md chunk size is
> 64kb), some program requests 128kb of data to be read, does it mean
> we'll do 16 reads for 4kb from two drives? Even if we do, is it
> right/good ?

Actually it is a bit more complicated than that.
Md/raid5 tries to encourage the filesystem to submit read requests is sizes
that fit inside one chunk.  When md/raid5 gets such a read request,
and it is for a device that has not failed and no reshape is happening
(and maybe some other conditions), it will forward the read request
down to the drive that can serve it.

If any of these conditions aren't met, then the read request will
be split in to 4K chunks and each chunk will be handled separately,
possibly reconstructing from other devices if that is needed etc.
However if a number of consecutive 4K reads (or writes) are submitted
to a device, the driver for that device will normally assemble
those requests together into fewer larger requests so you shouldn't
get lots of little request going out to the device unless there
are lots of little requests coming down from the filesystem.

NeilBrown