Subject: Pseudo-tape driver (was Re: Does anyone do backups on CD-R?)
To: der Mouse <mouse@Rodents.Montreal.QC.CA>
From: Roger Brooks <R.S.Brooks@liverpool.ac.uk>
List: current-users
Date: 11/17/1999 16:19:47
On Wed, 17 Nov 1999, der Mouse wrote:


>It's not directly relevant to the CD-R question, but I have written a
>pseudo-tape driver that allows dump - or any other program - to
>continue thinking it's talking to a tape, when it's really talking to a
>program.  It comes with a program that stores the "tape" contents in a
>file, with framing information to identify tape record boundaries.
>Other programs could be written to talk to a remote tape drive, or
>compress/encrypt before writing to a real tape, or whatever your
>imagination can dream up.

Neat!  Presumably this device is a double-ended thing (rather like a pty)?
I was looking for something like this 5 years ago after a futile attempt at
duplicating Exabyte tapes produced by Networker backup.  The problem was
that Networker filled each tape to LEOT, and sometimes the copying process
hit LEOT on the output tape before all the data had been read from the input
tape.  You *can* write beyond LEOT on an Exabyte, but in some cases I was
even reaching physical EOT on the output before I'd read all the data from
the input.

What I wanted to do with a pseudo tape device was this (/dev/pmtm0 and
/dev/pmts0 are the master and slave ends of the pseudo tape):


Networker -> /dev/pmtm0 -> /dev/pmts0 -> tape-mirror daemon -> /dev/rst0
                                                |
                                                +------------> /dev/rst1

Or even:


Networker -> /dev/pmtm0 -> /dev/pmts0 -> tape-mirror daemon -> /dev/rst0
                                                |
                                                +-> RMT to remote drive

Whichever drive reached LEOT first would cause the tape mirror to return
an EOF to Networker, ensuring that the data would fit on both copies.
In the end we set up another backup server and ran two independent backups,
but this has the disadvantage that in a worst case we can't use tape 1 from
server A and tape 2 from server B.

I did consider having a go at a pseudo tape device then, but realised that
I'd also have to write a pseudo media-changer device (and a media-changer
mirror daemon, and a remote media-changer protocol).  This would have been
"interesting", as at one end we had an Exabyte EXB-120 with 4 drives and
120 tapes, while at the other end we had two IGM-ATL jukeboxes, each with
2 drives and 54 tapes.


Roger

------------------------------------------------------------------------------
Roger Brooks (Systems Programmer),          |  Email: R.S.Brooks@liv.ac.uk
Computing Services Dept,                    |  Tel:   +44 151 794 4441
The University of Liverpool,                |  Fax:   +44 151 794 4442
PO Box 147, Liverpool L69 3BX, UK           | 
------------------------------------------------------------------------------