Problems with exabyte

[Chris Myers]

In article <1289 at dgbt.uucp> phil at dgbt.crc.dnd.ca (Phil Blanchfield DGBT/DIP) writes:
>In article <9337 at batcomputer.tn.cornell.edu> hurf at tcgould.tn.cornell.edu (Hurf Sheldon) writes:
>>
>>/etc/dump "$LEVEL"usdf 4800 6666 /dev/nrmt1h /usr/users
>>
>> the '4800' is big enough for us to get the /usr/users partition in - at
>> 6666 the dump program figures about 75mb per 1200ft so you can calculate
>> accordingly (that it does this is new with 3.0 and designed to avoid
>> the tk-50 having a file spread over a tape boundary because it
>> can't restore one that is) I suppose you could use -d 10000 (the tk-70)
>> but most exabyte implementations mimic a tk50. I am not sure but
>> I believe the density might be moot as it doesn't seem to make
>> a difference in speed or tape length. - Just used to calculate when
>> to call for a new tape.

>From the manual I got with my Exabyte:

dump ${level}usdf 6000 54000 /dev/nrmt0h /partition

I have used these parameters to dump 560MB partitions to my Exabyte.  The
density and tape length parameters aren't used by dump for anything other
than calculating the amount of data that can be written to a single tape,
so all you have to do is pick numbers that won't cause a numeric overflow
(which can happen in older 'dump's).

>Does anyone know why the TK50 can't restore a file which is spread
>across two tapes? Has this been fixed in V3.1 or is this a hardware
>problem?

There is a bug in the Ultrix 3.x TAR program that prevents a multi-volume
tar file from being restored from a SCSI drive.  Call your DEC Serviceperson
and ask for a copy of the Ultrix 3.1 patch tape -- it has a fixed copy of
tar.
-- 
Chris Myers                                    Internet: chris at wugate.wustl.edu
Software Engineer                                  UUCP: ...!uunet!wugate!chris
Office of the Network Coordinator                    BITNET: chris at wunet.bitnet
Washington University in Saint Louis                     Phone: +1 314 362 6186