View Issue Details

IDProjectCategoryView StatusLast Update
0001239bareos-corestorage daemonpublic2023-12-13 13:36
Reporterkabassanov Assigned Tobruno-at-bareos  
PrioritynormalSeveritymajorReproducibilityhave not tried
Status closedResolutionno change required 
PlatformLinuxOSDebianOS Version10
Product Version19.2.7 
Summary0001239: A running job stole a tape from another running job
DescriptionHi,

I'm not really sure if it is a bug or a limitation, but yesterday I saw an unexpected behavior.

There is a library with 2 tape readers.
I started a restore job JOB_REC_1 that needed 4 tapes, let's say T1,T2,T3,T4. While reading from T3, another scheduled backup job JOB_BACK_1 started. It was using T4. So when JOB_REC_1 asked for T4, it was not available (because used by JOB_BACK_1). Normal. So it started waiting for T4.
Some minutes later other jobs JOB_BACK_2, JOB_BACK_3, JOB_BACK_4 were queued (max 2 jobs in parallel in bareos config) . When JOB_BACK_1 finished, JOB_BACK_2 started writing to the tape. At this moment I was a little bit surprised to see it writing to the tape, because I was expecting that JOB_REC_1 should have priority for the tape. I waited some minutes, then JOB_BACK_3 started. In its logs I saw that it was "Ready to append to end of Volume R0B018L7 at file=1097". At this moment, JOB_REC_1 unloaded the tape from JOB_BACK_3 drive and loaded it in its drive. Of course JOB_BACK_3 got an IO error message: "Error: stored/block.cc:804 Write error at 1097:0 on device "Drive-2" (/dev/nst1). ERR=Erreur d'entrée/sortie." and Bareos changed tape status to full.

I think that restore process succeeded (even if job "failed", because Bareos found entry in its database that was not written to the tape).
When manually changed tape status back to Append, backup jobs succeeded (with a warning for JOB_BACK_3).

But I wonder if there is a bug in media locking…

Thanks.
TagsNo tags attached.

Activities

bruno-at-bareos

bruno-at-bareos

2023-09-04 17:11

manager   ~0005370

Hello, it this still reproducible in 22.1.0
To be able to reproduce the exact case, it is also advised to give the related configuration.
bruno-at-bareos

bruno-at-bareos

2023-12-13 13:36

manager   ~0005627

no feedback

Issue History

Date Modified Username Field Change
2020-05-12 11:27 kabassanov New Issue
2023-09-04 17:11 bruno-at-bareos Assigned To => bruno-at-bareos
2023-09-04 17:11 bruno-at-bareos Status new => feedback
2023-09-04 17:11 bruno-at-bareos Note Added: 0005370
2023-12-13 13:36 bruno-at-bareos Status feedback => closed
2023-12-13 13:36 bruno-at-bareos Resolution open => no change required
2023-12-13 13:36 bruno-at-bareos Note Added: 0005627