"A month of sundays ago Paul Clements wrote:" > "Peter T. Breuer" wrote: > > > > Can you shed some light on this for me? > > > > currspeed = > > (j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1; > > > > jiffies is divided by HZ here, which results in a quantity of dimension > > time-squared! > > > > I could understand it (better) if jiffies were multiplied by HZ. > > Just curious, but are you looking at this because the speed calculations > break when using a bitmap to resync? I realized this problem a few days Exactly so. > ago, but I'm not sure how to solve it, yet... Pushing speed_min up is a workaround. > 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... Possibly. There are a large number of possible solutions, but until I can understand what the speed calculation is supposed to be doing, I find myself unable to pick out a way forward. 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
