Force parity resync on raid5?

Force parity resync on raid5?

[Philip Molter]

How do I force a parity resync on a raid5 array?  Under 2.4, I would do 
this by hard cycling the box and when it came back up, it would 
automatically resync the array.  Under 2.6, this appears to have gone away.

I suspect I have parity corruption on several boxes (they run fine 
normally, but when they lose a drive, they then get corrupted) related 
to the raid5 resync bug from an older kernel.  I want to force the 
parity to reinitialize since all the data is definitely good.

Thank you for any advice.
Philip

Re: Force parity resync on raid5?

[Gordon Henderson]

On Mon, 9 Aug 2004, Philip Molter wrote:

> How do I force a parity resync on a raid5 array?  Under 2.4, I would do
> this by hard cycling the box and when it came back up, it would
> automatically resync the array.  Under 2.6, this appears to have gone away.

I don't know about 2.6, (still living with 2.4) but can't you simply do:

  raidhotremove /dev/mdX /dev/hdYZ

followed by

  raidhotadd /dev/mdX /dev/hdYZ

or /dev/sdYZ if SCSI disks...

However, picking the right disk to remove might be tricky... And if you
were at all unsure about data on the disks, maybe rebooting and doing a
hard fsck of the partition(s) in maintenance mode might be a good thing
too...

Good luck!

RE: Force parity resync on raid5?

[Guy]

Ouch!  No!!

This would re-build data from parity!!!
He thinks his parity is bad.
He wants to re-build the parity from the data!
I don't know if this can even be done!
Recovering from a power failure does force a re-build (2.4), but from what I
remember the system looks like it is re-building a failed disk, which is not
what he wants to do.  If the parity was good, re-building any 1 disk would
be fine.

Guy

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Gordon Henderson
Sent: Tuesday, August 10, 2004 5:04 AM
To: Philip Molter
Cc: linux-raid@vger.kernel.org
Subject: Re: Force parity resync on raid5?

On Mon, 9 Aug 2004, Philip Molter wrote:

> How do I force a parity resync on a raid5 array?  Under 2.4, I would do
> this by hard cycling the box and when it came back up, it would
> automatically resync the array.  Under 2.6, this appears to have gone
away.

I don't know about 2.6, (still living with 2.4) but can't you simply do:

  raidhotremove /dev/mdX /dev/hdYZ

followed by

  raidhotadd /dev/mdX /dev/hdYZ

or /dev/sdYZ if SCSI disks...

However, picking the right disk to remove might be tricky... And if you
were at all unsure about data on the disks, maybe rebooting and doing a
hard fsck of the partition(s) in maintenance mode might be a good thing
too...

Good luck!
-
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: Force parity resync on raid5?

[Philip Molter]

> Recovering from a power failure does force a re-build (2.4), but from what I
> remember the system looks like it is re-building a failed disk, which is not
> what he wants to do.  If the parity was good, re-building any 1 disk would
> be fine.

Actually, under a 2.4, the superblock is marked dirty and the parity is 
rebuilt.  We've done this to over 100 systems (thank you, broken RedHat 
installer) and it's worked flawlessly.

Neil, the new mdadm --update=resync works like a charm.  The one thing I 
did notice is that when a drive fails out during the resync, the resync 
restarts on the remaining failed drives.  As far as I can tell, that 
does what it's supposed to.  Is that a nice little feature of the resync?

Philip

Re: Force parity resync on raid5?

[David Greaves]

what about
n=0
while
  dd if=/dev/md0 of=/tmp/block count=x_for_efficiency seek=n
  dd of=/dev/md0 if=/tmp/block count=x_for_efficiency seek=n
  n=n+1
loop

?

This would read the good data and force a rewrite - would you need to 
stop any optimisers?

David

Guy wrote:

>Ouch!  No!!
>
>This would re-build data from parity!!!
>He thinks his parity is bad.
>He wants to re-build the parity from the data!
>I don't know if this can even be done!
>Recovering from a power failure does force a re-build (2.4), but from what I
>remember the system looks like it is re-building a failed disk, which is not
>what he wants to do.  If the parity was good, re-building any 1 disk would
>be fine.
>
>Guy
>
>-----Original Message-----
>From: linux-raid-owner@vger.kernel.org
>[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Gordon Henderson
>Sent: Tuesday, August 10, 2004 5:04 AM
>To: Philip Molter
>Cc: linux-raid@vger.kernel.org
>Subject: Re: Force parity resync on raid5?
>
>On Mon, 9 Aug 2004, Philip Molter wrote:
>
>  
>
>>How do I force a parity resync on a raid5 array?  Under 2.4, I would do
>>this by hard cycling the box and when it came back up, it would
>>automatically resync the array.  Under 2.6, this appears to have gone
>>    
>>
>away.
>
>I don't know about 2.6, (still living with 2.4) but can't you simply do:
>
>  raidhotremove /dev/mdX /dev/hdYZ
>
>followed by
>
>  raidhotadd /dev/mdX /dev/hdYZ
>
>or /dev/sdYZ if SCSI disks...
>
>However, picking the right disk to remove might be tricky... And if you
>were at all unsure about data on the disks, maybe rebooting and doing a
>hard fsck of the partition(s) in maintenance mode might be a good thing
>too...
>
>Good luck!
>-
>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
>
>-
>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: Force parity resync on raid5?

[Guy]

You were using skip/seek wrong.
This is just pseudo code?  I use bash or ksh, you can't do "n=n+1".
You don't ever end, again pseudo code I assume.
I would only do this if the filesystem on md0 is not mounted.

Guy

n=0
while
  dd if=/dev/md0 of=/tmp/block count=x_for_efficiency skip=n
  dd of=/dev/md0 if=/tmp/block count=x_for_efficiency seek=n
  n=n+1
loop

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of David Greaves
Sent: Thursday, August 12, 2004 8:31 AM
To: Guy
Cc: 'Gordon Henderson'; 'Philip Molter'; linux-raid@vger.kernel.org
Subject: Re: Force parity resync on raid5?

what about
n=0
while
  dd if=/dev/md0 of=/tmp/block count=x_for_efficiency seek=n
  dd of=/dev/md0 if=/tmp/block count=x_for_efficiency seek=n
  n=n+1
loop

?

This would read the good data and force a rewrite - would you need to 
stop any optimisers?

David

Guy wrote:

>Ouch!  No!!
>
>This would re-build data from parity!!!
>He thinks his parity is bad.
>He wants to re-build the parity from the data!
>I don't know if this can even be done!
>Recovering from a power failure does force a re-build (2.4), but from what
I
>remember the system looks like it is re-building a failed disk, which is
not
>what he wants to do.  If the parity was good, re-building any 1 disk would
>be fine.
>
>Guy
>
>-----Original Message-----
>From: linux-raid-owner@vger.kernel.org
>[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Gordon Henderson
>Sent: Tuesday, August 10, 2004 5:04 AM
>To: Philip Molter
>Cc: linux-raid@vger.kernel.org
>Subject: Re: Force parity resync on raid5?
>
>On Mon, 9 Aug 2004, Philip Molter wrote:
>
>  
>
>>How do I force a parity resync on a raid5 array?  Under 2.4, I would do
>>this by hard cycling the box and when it came back up, it would
>>automatically resync the array.  Under 2.6, this appears to have gone
>>    
>>
>away.
>
>I don't know about 2.6, (still living with 2.4) but can't you simply do:
>
>  raidhotremove /dev/mdX /dev/hdYZ
>
>followed by
>
>  raidhotadd /dev/mdX /dev/hdYZ
>
>or /dev/sdYZ if SCSI disks...
>
>However, picking the right disk to remove might be tricky... And if you
>were at all unsure about data on the disks, maybe rebooting and doing a
>hard fsck of the partition(s) in maintenance mode might be a good thing
>too...
>
>Good luck!
>-
>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
>
>-
>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
>
>  
>

-
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: Force parity resync on raid5?

[David Greaves]

Guy wrote:

>You were using skip/seek wrong.
>  
>
typo - thanks.

>This is just pseudo code?  I use bash or ksh, you can't do "n=n+1".
>You don't ever end, again pseudo code I assume.
>  
>
Indeed - should have said - I wouldn't want anyone to cut'n'paste :)
(and that typo shows why!)

>I would only do this if the filesystem on md0 is not mounted.
>  
>
Yes - I thought it would be safe for / in single user and realised it 
wouldn't.
I was also thinking

n=0
while
  dd if=/dev/md0 of=/tmp/block count=x_for_efficiency skip=n
  dd of=/dev/md0 if=/dev/zero count=x_for_efficiency seek=n
  dd of=/dev/md0 if=/tmp/block count=x_for_efficiency seek=n
  n= n + 1
loop

in case something in a block/md layer was smart enough to see no changes 
and not write it for real - I really don't know but it's more paranoid.

Anyway - the question remains - would this be the right approach?

Hmm - I wonder what would be needed to make the resync code do this...

David

>Guy
>
>n=0
>while
>  dd if=/dev/md0 of=/tmp/block count=x_for_efficiency skip=n
>  dd of=/dev/md0 if=/tmp/block count=x_for_efficiency seek=n
>  n=n+1
>loop
>
>-----Original Message-----
>From: linux-raid-owner@vger.kernel.org
>[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of David Greaves
>Sent: Thursday, August 12, 2004 8:31 AM
>To: Guy
>Cc: 'Gordon Henderson'; 'Philip Molter'; linux-raid@vger.kernel.org
>Subject: Re: Force parity resync on raid5?
>
>what about
>n=0
>while
>  dd if=/dev/md0 of=/tmp/block count=x_for_efficiency seek=n
>  dd of=/dev/md0 if=/tmp/block count=x_for_efficiency seek=n
>  n=n+1
>loop
>
>?
>
>This would read the good data and force a rewrite - would you need to 
>stop any optimisers?
>
>David
>
>Guy wrote:
>
>  
>
>>Ouch!  No!!
>>
>>This would re-build data from parity!!!
>>He thinks his parity is bad.
>>He wants to re-build the parity from the data!
>>I don't know if this can even be done!
>>Recovering from a power failure does force a re-build (2.4), but from what
>>    
>>
>I
>  
>
>>remember the system looks like it is re-building a failed disk, which is
>>    
>>
>not
>  
>
>>what he wants to do.  If the parity was good, re-building any 1 disk would
>>be fine.
>>
>>Guy
>>
>>-----Original Message-----
>>From: linux-raid-owner@vger.kernel.org
>>[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Gordon Henderson
>>Sent: Tuesday, August 10, 2004 5:04 AM
>>To: Philip Molter
>>Cc: linux-raid@vger.kernel.org
>>Subject: Re: Force parity resync on raid5?
>>
>>On Mon, 9 Aug 2004, Philip Molter wrote:
>>
>> 
>>
>>    
>>
>>>How do I force a parity resync on a raid5 array?  Under 2.4, I would do
>>>this by hard cycling the box and when it came back up, it would
>>>automatically resync the array.  Under 2.6, this appears to have gone
>>>   
>>>
>>>      
>>>
>>away.
>>
>>I don't know about 2.6, (still living with 2.4) but can't you simply do:
>>
>> raidhotremove /dev/mdX /dev/hdYZ
>>
>>followed by
>>
>> raidhotadd /dev/mdX /dev/hdYZ
>>
>>or /dev/sdYZ if SCSI disks...
>>
>>However, picking the right disk to remove might be tricky... And if you
>>were at all unsure about data on the disks, maybe rebooting and doing a
>>hard fsck of the partition(s) in maintenance mode might be a good thing
>>too...
>>
>>Good luck!
>>-
>>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
>>
>>-
>>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
>>
>> 
>>
>>    
>>
>
>-
>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
>
>-
>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: Force parity resync on raid5?

[Philip Molter]

> Anyway - the question remains - would this be the right approach?
> 
> Hmm - I wonder what would be needed to make the resync code do this...

No, it wouldn't.  In RAID5 implementations, parity isn't recalculated 
when you write to a RAID,  It's updated.  My understanding is that 
typical implementations are, *VERY* basically:

read the old data
xor with the new data
read the parity data
xor with the parity data
write the new data
write the new parity data

Thus a RAID5 write is really two disk reads and two disk writes, which 
is why RAID5 is expensive for writing.  Under this scheme, if the parity 
is bad, and you write data to "update" it, it's still bad because you 
haven't recalculated anything.  If the parity is good, everything stays 
in sync.

If you were to truly recalculate parity every time you wrote to a block, 
it'd be something like:

write the new data
read the corresponding data blocks from the other drives
recalculate parity based on all blocks
write the new parity data

That would be n-1 reads and 2 writes for every write, which would get 
expensive as your number of drives increased.  It's something like this 
that the update=resync option in mdadm does, that is it reads every 
drive's data and actually recalculates the parity based on that.

Philip

Re: Force parity resync on raid5?

[Philip Molter]

Gordon Henderson wrote:

> On Mon, 9 Aug 2004, Philip Molter wrote:
> 
> 
>>How do I force a parity resync on a raid5 array?  Under 2.4, I would do
>>this by hard cycling the box and when it came back up, it would
>>automatically resync the array.  Under 2.6, this appears to have gone away.
> 
> 
> I don't know about 2.6, (still living with 2.4) but can't you simply do:
> 
>   raidhotremove /dev/mdX /dev/hdYZ
> 
> followed by
> 
>   raidhotadd /dev/mdX /dev/hdYZ
> 
> or /dev/sdYZ if SCSI disks...
> 
> However, picking the right disk to remove might be tricky... And if you
> were at all unsure about data on the disks, maybe rebooting and doing a
> hard fsck of the partition(s) in maintenance mode might be a good thing
> too...

Nope, I want something that will specifically resync the parity from the
known good data on the disks.  Thanks to the raid5 resync bug from
earlier 2.6 kernels, I have hundreds of systems with terabytes of data
that have perfectly good data sitting on raid5 arrays with corrupt
parity.  If I remove a drive to force a resync, the data is immediately
corrupted.

Linux RAID *has* to have sort of way to force a parity resync.  If it
doesn't have one, it needs one.  That's a glaring omission to make.

Philip

Re: Force parity resync on raid5?

[Neil Brown]

On Tuesday August 10, philip@corp.texas.net wrote:
> 
> Linux RAID *has* to have sort of way to force a parity resync.  If it
> doesn't have one, it needs one.  That's a glaring omission to make.

Well, you get what you pay for.....

The easiest way to force a resync would be to re-create the array.

 - Note the exact order of the drives in the array, and the chunk size.
 - Stop the array.
 - Create the array with mdadm using --force.  That bit is important.

    mdadm --create /dev/mdX --level=5 --force --disks=whatever \
       --chunksize=64k  /dev/sda1 /dev/sdb1 .....

 Remember the --force.  If you don't have it, you will get a recovery
 cycle that rebuilds one drive against the others rather than a resync
 that checks and corrects parity.

 This will recreate the array (almost) exactly as it currently is, but
 it will not be marked 'clean', so a parity check-and-correct will
 happen.

 It should be fairly easy to add a --update=dirty option to
    "mdadm --assemble"
 to make that a bit easier.  I might do that in a  day or two (though
 I might not).

 Ofcourse, it would be really nice if you could just tell md to run a
 resync pass.  It's on my todo list, but it isn't the only thing.
 Clean, well-designed, small patches gladly accepted.

NeilBrown

(don't forget the --force)

Re: Force parity resync on raid5?

[Philip Molter]

Neil Brown wrote:

> On Tuesday August 10, philip@corp.texas.net wrote:
> 
>>Linux RAID *has* to have sort of way to force a parity resync.  If it
>>doesn't have one, it needs one.  That's a glaring omission to make.
> 
> Well, you get what you pay for.....

Tell me where to send the checks.  Seriously.  I know you guys work hard 
on this stuff and I will gladly donate to the fund to have important (to 
me) features implemented.

> The easiest way to force a resync would be to re-create the array.
> 
>  - Note the exact order of the drives in the array, and the chunk size.
>  - Stop the array.
>  - Create the array with mdadm using --force.  That bit is important.

Do I need to note the parity algorithm, too?

>     mdadm --create /dev/mdX --level=5 --force --disks=whatever \
>        --chunksize=64k  /dev/sda1 /dev/sdb1 .....
> 
>  Remember the --force.  If you don't have it, you will get a recovery
>  cycle that rebuilds one drive against the others rather than a resync
>  that checks and corrects parity.
> 
>  This will recreate the array (almost) exactly as it currently is, but
>  it will not be marked 'clean', so a parity check-and-correct will
>  happen.

Does this destroy the data on the array?  I seem to remember getting 
this advice a while back when encountering a similar problem and seeing 
my data go up in smoke.  I could easily have done something wrong, though.

Re: Force parity resync on raid5?

[Neil Brown]

On Tuesday August 10, philip@corp.texas.net wrote:
> Neil Brown wrote:
> 
> > On Tuesday August 10, philip@corp.texas.net wrote:
> > 
> >>Linux RAID *has* to have sort of way to force a parity resync.  If it
> >>doesn't have one, it needs one.  That's a glaring omission to make.
> > 
> > Well, you get what you pay for.....
> 
> Tell me where to send the checks.  Seriously.  I know you guys work hard 
> on this stuff and I will gladly donate to the fund to have important (to 
> me) features implemented.

Hmmm. Awkward.
I'm not averse to doing a bit of contracting at times (taking un-paid
leave or similar from my day job), but having a fund that people can
donate to might be a bit more awkward...


> 
> > The easiest way to force a resync would be to re-create the array.
> > 
> >  - Note the exact order of the drives in the array, and the chunk size.
> >  - Stop the array.
> >  - Create the array with mdadm using --force.  That bit is important.
> 
> Do I need to note the parity algorithm, too?

Yes, though I strongly suspect the array was created with the default
parity algorithm, so it shouldn't make any difference.

> 
> >     mdadm --create /dev/mdX --level=5 --force --disks=whatever \
> >        --chunksize=64k  /dev/sda1 /dev/sdb1 .....
> > 
> >  Remember the --force.  If you don't have it, you will get a recovery
> >  cycle that rebuilds one drive against the others rather than a resync
> >  that checks and corrects parity.
> > 
> >  This will recreate the array (almost) exactly as it currently is, but
> >  it will not be marked 'clean', so a parity check-and-correct will
> >  happen.
> 
> Does this destroy the data on the array?  I seem to remember getting 
> this advice a while back when encountering a similar problem and seeing 
> my data go up in smoke.  I could easily have done something wrong, though.

No, it doesn't destroy the data - provided you have the configuration
exactly the same as before.  It will only update the superblocks and
correct all parity blocks.  Data blocks won't be changed.

However I have just release mdadm 1.7.0 which supports
   --assemble --update=resync

which will cause an array to resync immediately after being
assembling.  This don't help you for an array with a root filesystem
on it, but should do want you want for any other array.

NeilBrown

Re: Force parity resync on raid5?

[Philip Molter]

> However I have just release mdadm 1.7.0 which supports
>    --assemble --update=resync
> 
> which will cause an array to resync immediately after being
> assembling.  This don't help you for an array with a root filesystem
> on it, but should do want you want for any other array.

Neil,

Thank you.  I'll let you know if we have any problems with the resyncing.

Philip

Re: Force parity resync on raid5?

[David Greaves]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Neil Brown wrote:

|On Tuesday August 10, philip@corp.texas.net wrote:
|
|>Neil Brown wrote:
|>
|>>On Tuesday August 10, philip@corp.texas.net wrote:
|>>
|>>>Linux RAID *has* to have sort of way to force a parity resync.  If it
|>>>doesn't have one, it needs one.  That's a glaring omission to make.
|>>
|>>Well, you get what you pay for.....
|>
|>Tell me where to send the checks.  Seriously.  I know you guys work
hard
|>on this stuff and I will gladly donate to the fund to have important
(to
|>me) features implemented.
|
|Hmmm. Awkward.
|I'm not averse to doing a bit of contracting at times (taking un-paid
|leave or similar from my day job), but having a fund that people can
|donate to might be a bit more awkward...

So, given a request for a feature:
Set up a page with a rough estimate of the cost. eg, parity resync: 2
weeks effort @ £500/day (casually picked this as a v. cheap
'commercial consultant rate' - reasonable contract rate) is £5000.
Detailed estimate + design maybe a day or more at the same rate (maybe
just if anyone were to ask or mandatory if you felt you would need to
do this before committing to a feature).
You could add promise emails to the total (eg company X may promise
£2k but not until the rest has been promised up)
If you wanted to use a non-refundable paypal type account and update
the page as thankyous/donations/promises arrive, that could give
people an idea of the likely commitment elsewhere in the community -
and if you get a few £10 thankyous from home users then maybe it'll
affect your priority for stuff you'd have done at some point anyway.

And put the url in your .sig :)

Just a thought.

David

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBGeWN8LvjTle4P1gRApKmAJ4s+gngPl8W0FGqe2HduYQnkUuSPACePFJ2
p/a2zGQLm6xr8Ya/CRaKTOc=
=tWTX
-----END PGP SIGNATURE-----

-
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: Force parity resync on raid5?

[Salyzyn, Mark]

But, does this occur for full stripe writes?

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Philip Molter
Sent: Thursday, August 12, 2004 1:08 PM
To: linux-raid@vger.kernel.org
Subject: Re: Force parity resync on raid5?

No, it wouldn't.  In RAID5 implementations, parity isn't recalculated 
when you write to a RAID,  It's updated.  My understanding is that 
typical implementations are, *VERY* basically:

read the old data
xor with the new data
read the parity data
xor with the parity data
write the new data
write the new parity data

RE: Force parity resync on raid5?

[Guy]

Neil once said md is smart enough to do whichever method takes less disk io.
It will read, read, write, write if it cost less than write the whole
stripe.  So a full stripe write would re-do the parity.  Maybe the dd block
size should be an even multiple of the stripe size.

From an email dated 6/9/2004:
" md sometimes does a "read-modify-write" cycle like your first example, and
sometimes does a "reconstruct-write" cycle like your second example.  It
chooses the option that generates the fewest IO requests.

NeilBrown"

A new option was added to mdadm:
"--update=resync for --assemble mode to for a resync when the
        array is assembled."

But until you can upgrade, the dd trick should be good.  If the filesystem
is not mounted and the dd block size is a multiple of the strip size.

Guy

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Salyzyn, Mark
Sent: Thursday, August 12, 2004 1:15 PM
To: Philip Molter; linux-raid@vger.kernel.org
Subject: RE: Force parity resync on raid5?

But, does this occur for full stripe writes?

-----Original Message-----
From: linux-raid-owner@vger.kernel.org
[mailto:linux-raid-owner@vger.kernel.org] On Behalf Of Philip Molter
Sent: Thursday, August 12, 2004 1:08 PM
To: linux-raid@vger.kernel.org
Subject: Re: Force parity resync on raid5?

No, it wouldn't.  In RAID5 implementations, parity isn't recalculated 
when you write to a RAID,  It's updated.  My understanding is that 
typical implementations are, *VERY* basically:

read the old data
xor with the new data
read the parity data
xor with the parity data
write the new data
write the new parity data

-
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