Re: [patch 0/5] Journal guided resync and support

[Andreas Dilger]

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-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/