Question about SCSI tape transfers

[Dave Dickerson]

Occasionally, on my OSR505 system, I have to copy the
contents of a Travan5 tape to a Travan4 tape.

I have both tape drives connected to a common SCSI HA
and each drive is set to an unique SCSI ID and the
transfer is performed using the dd command, such as:

dd if=/dev/rStp0 of=/dev/rStp1

There are security implications for me if the bits
touch, say, the hard drive or are cached or buffered
somewhere on the system outside of the drive-HA-drive
path.

Question: as the bits flow from one tape cartridge
to the other, do they ever "touch" any component of
the system other than the HA and tape drives?

TIA.

DDinAZ

[Dave Dickerson]

On Fri, 11 Jul 2003 23:08:08 GMT, Bela Lubkin <belal@sco.com> wrote:

>Dave Dickerson wrote:
>

>> Occasionally, on my OSR505 system, I have to copy the
>> contents of a Travan5 tape to a Travan4 tape.
>>
>> I have both tape drives connected to a common SCSI HA
>> and each drive is set to an unique SCSI ID and the
>> transfer is performed using the dd command, such as:
>>
>> dd if=/dev/rStp0 of=/dev/rStp1
>>
>> There are security implications for me if the bits
>> touch, say, the hard drive or are cached or buffered
>> somewhere on the system outside of the drive-HA-drive
>> path.
>>
>> Question: as the bits flow from one tape cartridge
>> to the other, do they ever "touch" any component of
>> the system other than the HA and tape drives?

>
>The data is buffered in main system memory -- OpenServer does not
>orchestrate direct SCSI target-to-target transfers. Also, since `dd` is
>a user-level process, its memory image _could_ get written to swap space
>if the system was busy enough to be swapping during the transfer. This
>is altogether unlikely on modern systems, but you should be aware of the
>possibility.
>
>To work around the swap issue, you could write your own data transfer
>program and use plock(S) to force your process not to be swapped. The
>process must run as root:
>
> #include <sys/lock.h>
>
> ...
> if (plock(DATLOCK) < 0) {
> perror("Cannot lock self in core (plock(DATLOCK))");
> exit(1);
> }
>
>Note that this is cleared by both fork() and exec(): you cannot use it
>to lock down `dd`, you have to write your own data transfer program. Of
>course it's a trivial program, in this case...
>

>>Bela<

Bela, your reply is very much appreciated.

Unfortunatly, writing even a trivial program is not an
option for my situation but it is very helpful to know
that data is touching the system during the transfer.

Thank you for the technical insight.

DDinAZ