The original post was:
>
> Trying to dump from FreeBSD 2.0R machine to OSF/1 V3.0 machine
> with DEC DAT tape TLZ07 attached there where some strange problems:
>
> Questions:
> 1) Tape density of TLZ07 (for high density device /dev/rmt0h) ?
> is it really 61000 BPI as written in /sys/data/cam_data.c (OSF/1)
> when dumping I got:
> irena /home/yuri 117 # rdump 0udsbf 61000 393 64 korney:/dev/nrmt0h /usr/local
> DUMP: Date of this level 0 dump: Wed Feb 15 10:56:02 1995
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /dev/rwd0g (/usr/local) to /dev/nrmt0h on host korney
> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 73197 tape blocks on 0.43 tape(s).
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: DUMP: 73875 tape blocks on 1 volumes(s)
> DUMP: level 0 dump on Wed Feb 15 10:56:02 1995
> DUMP: Closing /dev/nrmt0h
> DUMP: DUMP IS DONE
>
> 0.43 tape is not seem to be reasonable.
>
> 2)
>
> after that trying to rrestore:
>
> irena /home/yuri 125 # rrestore -if korney:/dev/nrmt0h
> resync restore, skipped 10 blocks \
> resync restore, skipped 1 blocks |
> resync restore, skipped 2 blocks | What's this ??
> resync restore, skipped 13 blocks /
Thanks to all who responded !
Here is a right answer by Guy Helmer:
I need to specify the same block size when restoring, as it was during dump.
My error !
---------------------------------------------------------------------------
Guy Helmer <ghelmer_at_alpha.dsu.edu>
I'm not sure about the TLZ07, but with our TLZ06 4mm 90M DDS tapes
(which I'm guessing is similar to the TLZ07) have a size (in feet) of
2640 according to the dump(1) man page on OSF/1 (393 seems quite small).
Just another "wild" guess, but don't you need to specify the block size
for the rrestore since you specified it in the rdump? rrestore may not
be determining the block size of the dump correctly.
I'm not running FreeBSD 2.0 yet (just 1.0, 1.1, and 1.1.5.1), so I'm not
sure my guesses are correct... I hope this helps, though.
Guy Helmer, Dakota State University Computing Services - ghelmer_at_alpha.dsu.edu
-------------------------------------------------------------------------------
another responces were:
magali_at_lune.lirmm.fr
My DecOSF version is 1.3, but I think it's the same thing.
I have an HP DAT
Dumps are from Decstations to DecAlpha :
rdump -0oudsf 61000 12000 decalpha:/dev/nrmt0h /fs
I had the same messages WITHOUT the "-o" option in rdump
>From "man rdump" Ultrix :
o Provides compatibility with non-ULTRIX or pre-ULTRIX Version 2.0
remote systems.
You should have an identical option in FreeBSD ?
Hope this helps
-------------------
Magali (magali_at_lirmm.fr)
Tel: (33) 67.41.85.70
--------------------------------------------------------------------------------
alan_at_nabeth.cxo.dec.com (Alan Rollow - Dr. File System's Home for Wayward Inodes.)
To answer the first question; maybe not. Dump only knows how to
estimate tape usage for 9 track tapes. For other tapes the density
and length have to be chosen so that the 9 track model works closely
enough. The values chosen may have little to do with how the tape
really work, though it probably helps to keep one of the parameters
correct and vary the other as necessary. The density may be
accurate, but the length could be chosen to make the model
work.
--------------------------------------------------------------------------------
Peter Fogarty <syspjf_at_devetir.qld.gov.au>
Answer for 1) is that I don't know of the top of my head. Sorry.
Answer for 2) is that you are trying to read back at a different block size to
the one that the tape was written with and so it keeps trying to re-sync the
block alignments and as such ends up missing some of the data. Because dump
write's its table of contents info at the start of the tape, it ends up missing
some of that data on the read. The directories are still on the tape, but you
have just not read the table of contents info for that entry.
I hope that makes sense.
--
Peter Fogarty - syspjf_at_devetir.qld.gov.au
DEVETIR -- Brisbane Qld AUSTRALIA
-------------------------------------------------------------------------------
Yuri Gindin
Sysadm & Programmer
Datcos Ltd. Israel
phone: +972-4774959
fax: +972-4774950
e-mail: aerygis_at_aluf.technion.ac.il
-------------------------------------------------------------------------------
Received on Tue Feb 21 1995 - 06:04:06 NZDT