stored: reserve/acquire a device on first incoming write data#1715
Merged
BareosBot merged 34 commits intobareos:masterfrom Sep 5, 2024
Merged
Conversation
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
from
56e2cf7 to
cc9d8dd
Compare
pstorz
requested changes
Feb 27, 2024
...rce/manually_added_config_directive_descriptions/sd-storage-MaximumNetworkBufferSize.rst.inc
Outdated
Show resolved
Hide resolved
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
from
03503d0 to
244f4db
Compare
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
3 times, most recently
from
d839d43 to
71cf93a
Compare
pstorz
changed the title
pstorz
changed the title
sebsura
commented
Apr 16, 2024
Contributor
Author
|
We should update the sd status message during the wait so we know what is happening. |
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
from
d8a167a to
dbf02f2
Compare
We use MNBS (SD->Storage) instead now. Also updates the MNBS documentation on the sd side.
Since the storage daemon bashes the spaces, we need to unbash them before printing.
reservations_lock_count was not used (and was used improperly), so it was removed. reservation_lock is defined as rwlock, but only ever used as a normal lock, so it was replaced by a std::mutex.
Sadly a lot of logic relies on the fact that jcr->dcr is always set and jcr->read_dcr is just sometimes set, as such we need to set both even when just reading (for now).
This should not happen since this function can be called during the backup, where OK_device/NO_device does not make sense anymore.
Since SetupinewDcrDevice accesses dcr, dcr can never be null after
if (rct.store->append) { ... }, so the if would have never fired.
Since the branches of the if are basically the same, the
SetupNewDcrDevice was extracted out of them.
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
from
2ae91aa to
04cda38
Compare
pstorz
approved these changes
Sep 3, 2024
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
from
461d811 to
538f310
Compare
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
4 times, most recently
from
6cec6ff to
4cffe99
Compare
sebsura
force-pushed
the
dev/ssura/master/only-reserve-device-if-something-to-do
branch
from
4cffe99 to
2b9c043
Compare
7 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Thank you for contributing to the Bareos Project!
The bareos reservation logic reseves a device relatively early in the job processing.
This causes problems especially when using hardware tape drives, because this expensive ressource is unnessesarily
blocked and is not available for other jobs.
This PR moves the device reservation to the latest possible moment, which is when the first data to be written arrives in the storage daemon.
If a job does not produce any data at all (e.g. because no data is available for an incremental job), the device is not reserved at all.
The only drawback in that case is that the information about the job that did not produce any data on the device is not recorded on the medium and could not be scanned into the database in case of a desaster recovery.
As no data was written, this is not a real drawback.
Please check
If you have any questions or problems, please give a comment in the PR.
Helpful documentation and best practices
Checklist for the reviewer of the PR (will be processed by the Bareos team)
Make sure you check/merge the PR using
devtools/pr-toolto have some simple automated checks run and a proper changelog record added.General
Source code quality
Tests