Thanks Brian Cline, that solved my question.

Finally, i've tried to add an argument when calling for Rsync program in the python code. It seems to work quite fine. I am still looking for an other way than modifying the python code.

For those who may be interested in, i changed : obj/replicator.py ( ~ L. 320) :

args = [ 'rsync', '--bwlimit=1000', // Added this part to limit the bandwith rate used by Rsync '--recursive', '--whole-file', '--human-readable', '--xattrs', '--itemize-changes', '--ignore-existing', '--timeout=%s' % self.rsync_io_timeout, '--contimeout=%s' % self.rsync_io_timeout, ] node_ip = rsync_ip(node['ip'])

and common/db_replicator (~ L. 175) :

popen_args = ['rsync', '--bwlimit=1000', '--quiet', '--no-motd', // I added the '--bwlimit=1000' to limit the bandwidth rate '--timeout=%s' % int(math.ceil(self.node_timeout)), '--contimeout=%s' % int(math.ceil(self.conn_timeout))]

After that, i've spread these modifications on all my nodes.

Finally, i've tried to add an argument when calling for Rsync program in the python code. It seems to work quite fine. I am still looking for an other way than modifying the python code.

For those who may be interested in, i changed : obj/replicator.py ( ~ L. 320) :

args = [ 'rsync', '--bwlimit=1000', // Added this part to limit the bandwith rate used by Rsync '--recursive', '--whole-file', '--human-readable', '--xattrs', '--itemize-changes', '--ignore-existing', '--timeout=%s' % self.rsync_io_timeout, '--contimeout=%s' % self.rsync_io_timeout, ] node_ip = rsync_ip(node['ip'])

and common/db_replicator (~ L. 175) :

popen_args = ['rsync', '--bwlimit=1000', '--quiet', '--no-motd', // I added the '--bwlimit=1000' to limit the bandwidth rate '--timeout=%s' % int(math.ceil(self.node_timeout)), '--contimeout=%s' % int(math.ceil(self.conn_timeout))]

After that, i've spread these modifications on all my nodes.

Thank you for the answer. I am going to look at these two solutions and it seems that traffic control may be really helpful. There is a last thing that disturbs me a bit.

While i am watching the packets going through my network, i am not able to really differenciate the packets moving from a PUT request (uploading an object via the API) to the packets moving because of a drive failure (unmounting 1 device for exemple).

In this way, when 1 disk fails, the replicator starts doing his job and copy the missing datas to another zone. For this time, i can't really use the swift API for another purpose, like listing objects on an account or something. And i feel like if i limit the rsync bandwidth the problem will still be the same but just longer. I wanted to know if you already somthing like that ?

I remember reading something, a few days ago, that was telling about the configuration of a number of nodes that are used directly when there is a PUT request against the cluster. I can't remember what was it exactly so if you have and idea ? Because i was wondering if the fact to have enough nodes configured to cumulate the functions it could resolve my problems. I mean, if you configure 1 node for PUT request, 3 replicas and there is 1 node which fails, maybe having 1+3+1=5 nodes separated in 5 zones could help ? This just is an idea, that i'll work on it.

Anyway, really thank you for the answer, and sorry for disturbing. Have a nice day.

Thank you for your answer. You understood the problem right. I am going to look at these solutions that seems really good and can rule the throughput rate the way i want. Thank you again for you help.