A.P. Lawrence

Best of the Newsgroups: dd from tape to tape

If this isn't exactly what you wanted, please try our Search (there's a LOT of techy and non-techy stuff here about Linux, Unix, Mac OS X and just computers in general!):

From: Bela Lubkin <belal@sco.com>
Subject: Re: Question about SCSI tape transfers
Date: Fri, 11 Jul 2003 23:08:08 GMT References: <3f0ea8c9.3746006@news4.sucknews.com>

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<