View Issue Details

IDProjectCategoryView StatusLast Update
0000009bareos-coredirectorpublic2013-06-21 17:15
Reportermvwieringen Assigned Topstorz  
Status closedResolutionfixed 
PlatformOpenIndianaOSOpenIndianaOS Versionb151a
Product Version12.4.1 
Fixed in Version12.4.1 
Summary0000009: Implementation of running Job speed limit.
DescriptionI noticed the need for an integrated bandwidth limiter for
running jobs. It would be very useful just to specify another
field in bacula-dir.conf, like speed = how much speed you wish
for that specific job to run at

Why: Because of a couple of reasons. First, it's very hard to implement a
     traffic shaping utility and also make it reliable. Second, it is very
     uncomfortable to have to implement these apps to, let's say 50 clients
     (including desktops, servers). This would also be unreliable because you
     have to make sure that the apps are properly working when needed; users
     could also disable them (accidentally or not). It would be very useful
     to provide Bacula this ability. All information would be centralized,
     you would not have to go to 50 different clients in 10 different
     locations for configuration; eliminating 3rd party additions help in
     establishing efficiency. Would also avoid bandwidth congestion,
     especially where there is little available.
Additional InformationRestore functionality that was opensource in Bacula but was reverted in a
sneaky cleanup commit.

See commit caaa5db722750df356ff4d5b3bedd2b9fe909e6e and
9267b18c0a9eaae7324174f4214ef74e762c04e3 on Branch-5.2 and search for bandwidth.

The documentation still documents this feature even when it was removed.

The following commits add the code to the 5.2 branch before it was removed:

TagsNo tags attached.




2012-12-16 13:05

developer   ~0000029

Fixed problem with bandwidth not being propagated from JobDef to Job.


2012-12-16 13:08

developer   ~0000030

Last edited: 2012-12-16 13:09

Make bandwidth limiting stay much closer to actual target by reusing the amount
of data left from previous timeslices to burst some more over time. This seems to
work much better as its now within 1% of the actual target (sometime a little
above the target but that is no real problem.) The old code wandered off to much
and at the end of the Job sometimes was more then 2% off the actual target
probably due to the fact it did a reset of the amount every timeslice when
it calculated the bandwidth still allowed.



2012-12-16 17:14

developer   ~0000031

make bandwidth bursting a configurable option.

Issue History

Date Modified Username Field Change
2012-12-05 15:08 mvwieringen New Issue
2012-12-05 15:08 mvwieringen Status new => assigned
2012-12-05 15:08 mvwieringen Assigned To => mvwieringen
2012-12-10 13:59 maik Category General => director
2012-12-16 13:05 mvwieringen Note Added: 0000029
2012-12-16 13:08 mvwieringen Note Added: 0000030
2012-12-16 13:08 mvwieringen Note Edited: 0000030
2012-12-16 13:09 mvwieringen Note Edited: 0000030
2012-12-16 17:14 mvwieringen Note Added: 0000031
2012-12-16 17:14 mvwieringen Time allocated Deleted 2012-12-16: 2,00 h. => deleted
2013-02-01 15:06 mvwieringen Target Version => 12.4.0
2013-02-01 15:06 mvwieringen Assigned To mvwieringen =>
2013-02-01 15:06 mvwieringen Status assigned => closed
2013-02-01 15:06 mvwieringen Resolution open => fixed
2013-02-10 11:10 mvwieringen Additional Information Updated
2013-03-04 10:38 mvwieringen Product Version => 12.4.1
2013-03-04 10:38 mvwieringen Fixed in Version => 12.4.1
2013-05-24 12:51 pstorz Assigned To => pstorz
2013-05-24 12:51 pstorz Status closed => resolved
2013-06-21 17:15 joergs Status resolved => closed