On 2009-11-24, at 04:43, Pavel Machek wrote:
This is an updated implementation of journal guided resync,
intended to be suitable for production systems. This feature
addresses the problem with RAID arrays that take too long to resync
- similar to the existing MD write-intent bitmap feature, we resync
only the stripes that were undergoing writes at the time of the
crash. Unlike write-intent bitmaps, our testing shows very little
performance degredation as a result of the feature - around 3-5% vs
around 30%
for bitmaps.
Good. Now when fs know about raid and wise versa... perhaps it is time
to journal surrounding data on stripe so that power fails do not
destroy data on degraded raid5?
That's an interesting idea. I suspect this could be done more
efficiently by only journaling the parity block update, but there is
no way for the journal to address this block.
That said, unfortunately Jody has no more time to work on these
patches (due to data ordering requirements Lustre can't use them), and
while they are functionally complete for RHEL5 + ext3, they need to be
ported to 2.6.current and ext4 by someone or they will die a silent
death.
Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
