Menu
▾
▴
[Bacula-bugs] [bacula 0001159]: Migration by Pool Occupancy: Migration Low Bytes does not work
|
From: <bac...@li...> - 2008-09-19 01:10:37
|
A NOTE has been added to this issue. ====================================================================== http://bugs.bacula.org/view.php?id=1159 ====================================================================== Reported By: slehmann Assigned To: ====================================================================== Project: bacula Issue ID: 1159 Category: Director Reproducibility: always Severity: major Priority: normal Status: feedback ====================================================================== Date Submitted: 09-18-2008 15:46 BST Last Modified: 09-19-2008 09:10 BST ====================================================================== Summary: Migration by Pool Occupancy: Migration Low Bytes does not work Description: In our environment we backup to disk. We use Pool occupancy to migrate the jobs from disk to tape. Works fine BUT: the pool-option "Migration Low Bytes" seem to not work. Migration start if the pool "Disk" reaches 600GB and should stop when it goes below 200GB, but bacula migrates any job from the disk pool that is not beeing migrated at this time. Sometimes a deathlook occures when bacula is reading from disk while a backupjob want's to write to the same. ====================================================================== ---------------------------------------------------------------------- kern - 09-18-08 16:20 ---------------------------------------------------------------------- It seems to me that you are reporting two bugs here, so it would be better if you open a second bug to report the deadlock situation. Concerning the Low Bytes level: there may be a bug in it. Basically before beginning the jobs, Bacula has a very simple algorithm that starts by looking at one job at a time counting the number of bytes that will be freed by migrating the job (or perhaps it is on a Volume basis, I forget). When the total amount exceeds the number of bytes needed, it stops looking for more jobs to migrate. Depending on the size of the last job it looked at the amount that remains may be well below the Low Bytes. If it is not following that algorithm, please show me an example of the Pool size before migration, the list of jobs migrated with their size, and the resulting size of the pool after the migration. You might also turn on debug code level 20 in the Director, that should give us some information on the decisions it is making (I might need to add more debug code). ---------------------------------------------------------------------- slehmann - 09-19-08 09:10 ---------------------------------------------------------------------- OK, the deathlock-Situation may be based on this bug, because it occurse if a job is spanning over two volumes. So we set the "Migration Low Bytes" to 200GB so that the last three volumes should be left out by migration. I have added the debug-output from the director as you said. I'm confused about the messages about pool occupancy, i don't understand the art of calculation of the low byte watermark, but you are the developer - hope you understand that. To ensure that i have some migration jobs i have set Migration High Byte to 300GB and Low Byte to 50GB. For me, it looks like the migration starts correctly, but the low byte watermark is never reached, so bacula migrates any job. This is because the "poolafter" calculation is made from the total pool size (1,3TB), not from his occupancy. Issue History Date Modified Username Field Change ====================================================================== 09-18-08 15:46 slehmann New Issue 09-18-08 16:20 kern Note Added: 0003646 09-18-08 16:20 kern Status new => feedback 09-19-08 09:10 slehmann Note Added: 0003651 ====================================================================== |