stored: explicitly flush after labeling#2022
Conversation
|
Could you add some more explanation ? From what i can tell, labeling just uses our normal write routines to write the data. For me this means that if the size is sometimes wrong during labeling, then it will also be wrong during normal writing or do i have that wrong ? E.g. if I have a test that writes a backup and then immediately tries to restore it. |
|
Also i though that reading from unfushed data works by reading it from the queue. If this is not the case, then reading should definitely flush the data first. (Maybe we can skip this if we can make sure that no data in the queue would affect our reads). |
ebd959c to
1dfd9da
Compare
|
So I managed to pinpoint the actual bug ( |
this is needed to make sure the volume is flushed to the backing storage so a subsequent read of the label will work.
While writing to a chunk, a call to ChunkedVolumeSize() would not return the correct size, as it got the size by either looking at the upload queue or asking the backend storage. The patch adds a third option: if the current chunk has been written, its last offset represents the end of the volume.
7f311ea to
72fdaaf
Compare
this is needed to make sure the volume is flushed to the backing storage so a subsequent read of the label will work.
This fixes #2020.
Thank you for contributing to the Bareos Project!
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