Re: patch fr1-2.17 does not work with kernel 2.4.30

On Sun, 10 Apr 2005 09:39:22 +0200 (MET DST)
"Peter T. Breuer" <[email protected]> wrote:

> "Also sprach Stephan von Krawczynski:"
> > On Sat, 9 Apr 2005 17:51:10 +0200 (MET DST)
> > "Peter T. Breuer" <[email protected]> wrote:
> > 
> > > "Also sprach Stephan von Krawczynski:"
> > > > I re-did the test according to FR1 readme with raidsetfaulty /
> > > > raidhotadd and found out it resyncs the whole raid although there
> > > > should be no difference between the two devices "out of sync".
> > > 
> > > Can you show me the kernel messages relating to that?
> > 
> > Sorry, here is another bunch of messages after finished sync:
> > 
> > Apr 10 09:02:35 mail-a01 kernel: raid1: skipped clean sectors 0-204799
> 
> This is a complete resync without rewriting anything. Looks like
> success to me!

Yes, you are right.

Playing around with the values of /proc/sys/dev/raid/speed_limit_min I
understood the reasons for slow/fast recovery.
What's left is that I think the bitmap patch should not interact with the
speed_limit as it does now.
The problem is that the design goal of the speed_limit was to not over-stress
the box with fast-and-resource-consuming resync. The real bad boy in resync is
obviously the i/o stuff. But if there is no i/o taking place (like with clean
sectors) I guess these should not count as "written" in the sense of the
speed_limit. As there was no i/o the driver should not think he might have to
delay to not over-stress the box.
Do you get my idea?
Is there a short-path to take clean sectors out of the speed_limit calculation?

Nevertheless this is a great piece of software, thanks a lot Peter.

Regards,
Stephan