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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130123152044.3726fb4e@notabene.brown>
Date:	Wed, 23 Jan 2013 15:20:44 +1100
From:	NeilBrown <neilb@...e.de>
To:	device-mapper development <dm-devel@...hat.com>
Cc:	mpatocka@...hat.com, Guangliang Zhao <gzhao@...e.com>,
	linux-kernel@...r.kernel.org, agk@...hat.com
Subject: Re: [dm-devel] [PATCH 0/3 v3] add resync speed control for dm-raid1

On Tue, 22 Jan 2013 20:44:41 -0500 (EST) Mikulas Patocka
<mpatocka@...hat.com> wrote:

> 
> 
> 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.

Sounds good ..... not that easy though.

But if the disk is otherwise idle, I want 100% of the time to be spend on
synchronisation.  If it isn't otherwise idle, I want a much more modest
faction to be used.

Getting this "right" is very hard.  You want to resync aggressively if there
is no other traffic, but to back off quickly to some small background rate if
there is any other traffic.  That is what md tries to do.

dm-raid1 has an extra complication.  It is used in clusters (clvm) where
multiple separate hosts might be accessing the device.  So the host which is
driving the resync cannot know what other IO there might be.
In that case the only thing that seems to be practical is an maximum sync
speed that can be set by the admin.

NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)