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@xxxxxxxxxxxxxxx
[mailto:linux-raid-owner@xxxxxxxxxxxxxxx] On Behalf Of Salyzyn, Mark
Sent: Thursday, August 12, 2004 1:15 PM
To: Philip Molter; linux-raid@xxxxxxxxxxxxxxx
Subject: RE: Force parity resync on raid5?
But, does this occur for full stripe writes?
-----Original Message-----
From: linux-raid-owner@xxxxxxxxxxxxxxx
[mailto:linux-raid-owner@xxxxxxxxxxxxxxx] On Behalf Of Philip Molter
Sent: Thursday, August 12, 2004 1:08 PM
To: linux-raid@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
