[dm-devel] Re: Regarding dm-ioband tests

[Ryo Tsuruta <ryov valinux co jp>]

Hi Vivek,

Vivek Goyal <vgoyal redhat com> wrote:
> > I think there are some advantages to dm-ioband. That's why I post
> > dm-ioband to the mailing list.
> > 
> > - dm-ioband supports not only proportional weight policy but also rate
> >   limiting policy. Besides, new policies can be added to dm-ioband if
> >   a user wants to control bandwidth by his or her own policy.
> 
> I think we can easily extent io scheduler based controller to also support
> max rate per group policy also. That should not be too hard. It is a
> matter of only keeping track of io rate per group and if a group is
> exceeding the rate, then schedule it out and move on to next group.
> 
> I can do that once proportional weight solution is stablized and gets
> merged. 
> 
> So its not an advantage of dm-ioband.

O.K.

> > - The dm-ioband driver can be replaced without stopping the system by
> >   using device-mapper's facility. It's easy to maintain.
> 
> We talked about this point in the past also. In io scheduler based
> controller, just move all the tasks to root group and you got a system
> not doing any io control.
> 
> By the way why would one like to do that? 
> 
> So this is also not an advantage.

My point is that dm-ioband can be updated for improvements and
bug-fixing without stopping the system.

> > - dm-ioband can use without cgroup. (I remember Vivek said it's not an
> >   advantage.)
> 
> I think this is more of a disadvantage than advantage. We have a very well
> defined functionality of cgroup in kernel to group the tasks. Now you are
> coming up with your own method of grouping the tasks which will make life
> even more confusing for users and application writers.
> 
> I don't understand what is that core requirement of yours which is not met
> by io scheduler based io controller. range policy control you have
> implemented recently. I don't think that removing dm-ioband module
> dynamically is core requirement. Also whatever you can do with additional 
> grouping mechanism, you can do with cgroup also.
> 
> So if there is any of your core functionality which is not fulfilled by
> io scheduler based controller, please let me know. I will be happy to look
> into it and try to provide that feature. But looking at above list, I am
> not convinced that any of the above is a compelling argument for dm-ioband
> inclusion.

As I wrote in another email, I would like to make use of dm-ioband on
the system which doesn't support cgroup such as RHEL. In addition,
there are devices which doesn't use standard IO schedulers, and
dm-ioband can work on even such devices.

Thanks,
Ryo Tsuruta