Re: calc. of currspeed in md.c code in 2.4.20

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

 



"A month of sundays ago Paul Clements wrote:"
> "Peter T. Breuer" wrote:
>  
> > Correct me if this seems silly, but we could push speed_min up to equal
> > speed_max (or close) in the intervals in which the resync is skipping
> > sectors rather than syncing them. It does know.
> 
> But as soon as it hits the disk again, it's going to go to sleep,
> because the resync speed up to that point (when there was no real I/O)
> will be so high that it'll be way over the limits.

It'll be over the (newly set back to normal) minimum, but not over the
maximum. I don't have the code in sight at the moment ... doesn't it
use the max as a highwater mark, then?

Anyway, one could take the min back down to normal slowly.  Halving the
difference every group of sectors resynced might be OK.

Peter
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux RAID Wiki]     [ATA RAID]     [Linux SCSI Target Infrastructure]     [Linux Block]     [Linux IDE]     [Linux SCSI]     [Linux Hams]     [Device Mapper]     [Device Mapper Cryptographics]     [Kernel]     [Linux Admin]     [Linux Net]     [GFS]     [RPM]     [git]     [Yosemite Forum]


  Powered by Linux