Re: [dm-devel] [PATCH 0/3 v3] add resync speed control for dm-raid1

[Mikulas Patocka]

On Wed, 16 Jan 2013, Guangliang Zhao wrote:

> On Wed, Jan 09, 2013 at 12:43:21AM -0500, Mikulas Patocka wrote:
> > Hi
> Hi,
> 
> I think it is very good that your patches could be used for other
> targets(snapshot, thin) after reviewing yours, but I find some issues
> (maybe not, please correct me if I am wrong).
> 
> > 
> > I did this already some times ago.
> > I'm sending my patches in the next mail.
> > 
> > Basically, my and Guangliang's patches have the following differences:
> > 
> > my patch: uses per-module throttle settings
> > Guangliang's patch: uses per-device settings
> > (my patch could be changed to use per-device throttle too, but without 
> > userspace support it isn't much useful because userspace lvm can 
> > reload the mirror and per-device settings would be lost)
> 
> We couldn't force every devices in the system hold the same throttle,
> IMHO, per-device settings couldn't be ignored. 
> Setting the global value by the parameters of module is a good way, and
> it could also be used to set the default value in my patches. In this way,
> the global setting wouldn't be lost, and we could also adjust every device's
> speed.

It could be good to have per-device throttle.

> > my patch: uses fine grained throttling of the individual IOs in kcopyd - 
> > it measures active/inactive ratio and if the disk is active more than the 
> > specified percentage of time, sleep is inserted.
> 
> I think this policy might not be able to represent the exact write speed, 
> while other modules(such as md, drbd) monitor the real IO speed.

But you don't want to limit raid resynchronization to a certain speed. A 
disk has varying speed, it is faster in the beginning and slower in the 
end.

So if you want to limit raid resynchronization so that other tasks have 
faster access to the disk, you need to limit percentage of time that is 
spent on resynchronization, not resynchronization speed.

Mikulas
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/