View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0000322bareos-corestorage daemonpublic2014-07-18 15:262015-10-02 20:02
Reporterholtkamp Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionfixed 
PlatformLinuxOSRHELOS Version6
Product Version13.2.2 
Summary0000322: Make consecutive tape reads more like writing to tape (no rewinding between each job!)
DescriptionWhile copying lots of jobs from one tape to another, do not rewind the read tape all the time. That does not happen to the write tape, so it should be possible?

No problem for the first job that runs because it has to check the read tape and get everything in the proper position. But the next job should not need to rewind the read tape and just do a reposition to the next file that will be read.
Steps To Reproduce1) Have 2 tape drives
2) Have lots of jobs on pool A - tape A
3) Initiate copy of pool A - tape A jobs to pool B - tape B and order the jobids in the order they are on the tape (Selection type SQLQuery and some SQL magic)
4) SD will:
  a) find tape A to read from
  b) find tape B to write to
  c) make sure tape A can be read (by reading the label - acquire.c line 234 - this is the problem)
  d) forward tape B to append position (if not previously written only!)
  e) forward tape A to read position
  f) start spooling/copying data
Additional InformationStep C will be done for every job run even though the tape is not changed. This means the tape is always rewound and after that has to reposition itself even though it had been in the correct position before the rewind.

Maybe store label status for tape drives or something like that?
TagsNo tags attached.

Activities

holtkamp

holtkamp

2014-07-18 17:40

reporter  

reaquire-same-tape.diff (1,265 bytes)    
diff --git a/src/stored/acquire.c b/src/stored/acquire.c
index 8d14224..e338619 100644
--- a/src/stored/acquire.c
+++ b/src/stored/acquire.c
@@ -201,7 +201,9 @@ bool acquire_device_for_read(DCR *dcr)
       if (!dev->poll && retry++ > 10) {
          break;
       }
-      dev->clear_labeled();              /* force reread of label */
+      if (!bstrcmp(dev->VolHdr.VolumeName, dcr->VolumeName)) {
+        dev->clear_labeled();              /* force reread of label */
+      }
       if (job_canceled(jcr)) {
          char ed1[50];
          Mmsg1(dev->errmsg, _("Job %s canceled.\n"), edit_int64(jcr->JobId, ed1));
@@ -229,9 +231,13 @@ bool acquire_device_for_read(DCR *dcr)
       }
       Dmsg1(rdbglvl, "opened dev %s OK\n", dev->print_name());
 
-      /* Read Volume Label */
-      Dmsg0(rdbglvl, "calling read-vol-label\n");
-      vol_label_status = read_dev_volume_label(dcr);
+      if (bstrcmp(dev->VolHdr.VolumeName, dcr->VolumeName)) {
+        vol_label_status = VOL_OK;
+      } else {
+        /* Read Volume Label */
+        Dmsg0(rdbglvl, "calling read-vol-label\n");
+        vol_label_status = read_dev_volume_label(dcr);
+      }
       switch (vol_label_status) {
       case VOL_OK:
          Dmsg0(rdbglvl, "Got correct volume.\n");
reaquire-same-tape.diff (1,265 bytes)   
holtkamp

holtkamp

2014-07-18 17:41

reporter   ~0000933

Please evaluate, I have no idea what i am doing and if this might cause problems somewhere else, but it works :)
mvwieringen

mvwieringen

2014-07-18 21:53

developer   ~0000934

From a first analyze it doesn't look to bad but with the stored you never
know into what problems you run as its kind of strange how a lot of things
work. So we could try this approach (which I probably will guard by the fact
that you need to set always open = yes so the tape really cannot change so
we can depend a bit more on the fact that things don't change outside of our
control (I think for writing it also doesn't reread the tape label but also
kind of depends on the always open flag on the device.) Given the timing I will
have to postpone it for after we finish all other queued code at the moment.
But it does indeed looks like a thing that we might want to investigate and see
what impact it has.
holtkamp

holtkamp

2014-08-18 15:49

reporter   ~0000955

Fix committed to bareos master branch with changesetid 2012.
mvwieringen adm

mvwieringen adm

2015-01-26 16:06

administrator   ~0001222

Reverted as it breaks SCSI crypto.
mvwieringen

mvwieringen

2015-07-27 16:20

developer   ~0001792

Fix committed to bareos master branch with changesetid 5456.

Related Changesets

bareos: master 7bf1ea4f

2014-08-08 21:29

holtkamp

Ported: N/A

Details Diff		 Make consecutive tape reads more like writing to tape

No rewinding between each job! but if we need the same tape and
the device has the always open flag set the header cannot really change
so rereading it has little value. The Storage daemon should just
reposition the tape and start reading.

Fixes 0000322: Make consecutive tape reads more like writing to tape

Signed-off-by: Marco van Wieringen <marco.van.wieringen@bareos.com>		 Affected Issues
0000322
mod - src/stored/acquire.c Diff File

bareos: master 1b56f9a0

2014-08-08 23:29

holtkamp


Committer: mvwieringen

Ported: N/A

Details Diff		 Make consecutive tape reads more like writing to tape

No rewinding between each job! but if we need the same tape and
the device has the always open flag set the header cannot really change
so rereading it has little value. The Storage daemon should just
reposition the tape and start reading.

Fixes 0000322: Make consecutive tape reads more like writing to tape

Signed-off-by: Marco van Wieringen <marco.van.wieringen@bareos.com>		 Affected Issues
0000322
mod - src/stored/acquire.c Diff File

Issue History

Date Modified Username Field Change
2014-07-18 15:26 holtkamp New Issue
2014-07-18 17:40 holtkamp File Added: reaquire-same-tape.diff
2014-07-18 17:41 holtkamp Note Added: 0000933
2014-07-18 21:53 mvwieringen Note Added: 0000934
2014-07-18 22:05 mvwieringen Status new => acknowledged
2014-08-18 15:49 holtkamp Changeset attached => bareos master 7bf1ea4f
2014-08-18 15:49 holtkamp Note Added: 0000955
2014-08-18 15:49 holtkamp Assigned To => holtkamp
2014-08-18 15:49 holtkamp Status acknowledged => resolved
2014-08-18 15:49 holtkamp Resolution open => fixed
2015-01-26 16:06 mvwieringen adm Note Added: 0001222
2015-01-26 16:06 mvwieringen adm Assigned To holtkamp =>
2015-01-26 16:06 mvwieringen adm Status resolved => acknowledged
2015-07-27 16:20 mvwieringen Changeset attached => bareos master 1b56f9a0
2015-07-27 16:20 mvwieringen Note Added: 0001792
2015-07-27 16:20 mvwieringen Status acknowledged => resolved
2015-10-02 20:02 mvwieringen adm Status resolved => closed