[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-id: <856BC3CD-F483-4899-BCFE-0ACB59CED9BE@sun.com>
Date: Tue, 24 Nov 2009 11:51:34 -0700
From: Andreas Dilger <adilger@....com>
To: Pavel Machek <pavel@....cz>
Cc: scjody@....com, linux-ext4@...r.kernel.org,
linux-raid@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [patch 0/5] Journal guided resync and support
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists