DUPTAP performance should be improved

We recently found out, that DUPTAP has an expected behaviour that it takes twice as long as the SAVE-process. If the save-process exceeds 8 hours than one day (i.e. 24hrs) will not be enough to create a duplicate of the tape which is a requirement for banks for example.

It is not logical that a streaming input device which in our case (LTO7) can deliver data at a rate of 300MB/s and a writing device which can write 300MB/s work in a sequential way. I.e. it reads from the input tape, then it writes to the output tape and again. This results of course in a double time for the whole process.

Using a rolling buffer this should be a process running fairly in parallel and therefore having a better performance for the duplication. Maybe this might use a direct stream from input tape to output tape not involving much CPU cycles at all.

For a 6,5hour Fullbackup it took more than 13 hours to duplicate the tape. The job needed about 11 CPU seconds for this 13 hour work.

I thought using a rolling buffer in between that is written to at one side and read from another might solve this problem. We have 16 buffers in I/O for every path. I understood that todays SSDs are able to deliver data very fast, but a streaming device is able to deliver data at a streaming rate of the maximum for compressed data (which is 300MB/s at LTO7).

I understand that there will sometimes be a short delay. If it is not as fast as the backup that would not be a problem, it should be near the calculated optimum, but twice as long as the backup is a problem. At the moment it would be faster to do the backup twice than using the duplication process once the backup has been completed.

Please consider searching for a solution to this.