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

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

 



"Peter T. Breuer wrote:"
> > ago, but I'm not sure how to solve it, yet...
> 
> Pushing speed_min up is a workaround.

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.

Then nobody would have to change the (to me inscrutable) speed
calculation and throttling loop.

OTOH it would be nicer to have limits per device.

> > I think we might need two counters, one for the actual resync progress
> > (to display the progress bar, and show actual resync speed) and the
> > other to throttle I/O if actual I/O becomes too fast...


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