On Tue, Dec 1, 2015, at 10:25, Emmanuel Dreyfus wrote: > On Mon, Nov 30, 2015 at 12:26:33PM +0100, Giuseppe Ragusa wrote: > > The main scope for the present RFE is to allow bandwidth limiting for > > those cases where peers are clients too (and maybe the only clients), > > just like in an hyperconverged oVirt setup. > > I experienced the casof a client hogging the glusterfs cluster. In order > to mitigate this, bandiwth control is not enough: we need FOP rate limit > too. > > In an ideal world, there would be a setup to autoatically enforce it: > when FOP RTT increase (indicating a resource hog), make sure all clients > get an equal share of FOP execution slots. Yes, but that I think would end up more on the "internal" resource limiting side (like CPU resource limiting which I already cited, but IO/RAM/etc. could be equally important of course). > > As a final note, it would be fine if the goal could be reached by OS-level > > means > > That will be difficult to do in a portable way. Well, I did not mean to do that *inside* GlusterFS, only to facilitate it by modifying GlusterFS *external* behaviour. If you limit the scope of the RFE to network bandwidth limiting (for this RFE, the other points you made above still being important as you noted, but maybe could be the object of a dedicated RFE), maybe having dedicated and configuration-specified ports for the outgoing heal/rebalance/etc traffic could allow external OS-level tools to apply QoS policy, and I suppose that every sysadmin can apply that policy by its own with specific OS tools (like tc on Linux, on BSD I don't know, unfortunately) > -- > Emmanuel Dreyfus > manu@xxxxxxxxxx _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-devel
