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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux