Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 02 Jul 1998 08:44:05 -0500
From:      David Kelly <dkelly@hiwaay.net>
To:        wjw@IAEhv.nl
Cc:        hackers@FreeBSD.ORG
Subject:   Re: Apollo tapes (was: Variant Link implementation, continued) 
Message-ID:  <199807021344.IAA17009@nospam.hiwaay.net>
In-Reply-To: Message from Willem Jan Withagen <wjw@surf.IAE.nl>  of "Thu, 02 Jul 1998 09:36:27 %2B0200." <199807020736.JAA10898@surf.IAE.nl> 

next in thread | previous in thread | raw e-mail | index | archive | help
Willem Jan Withagen writes:
> 
> The tapes were written on a DAT (old non compressing) but for writting them
> I had to specify tar cbf 20 /dev/tape
> And I think it is this blocking factor which prevents me from even dd-ing
> data from the tape. :-(
> 
> Maybe I'll have to go to somebody with a driver which does 10K blocks?

As others have said, I don't understand what problem you are having yet
as FreeBSD's drivers can handle up to 64k blocks. I'd like to see that
size increased as often I have to deal with SGI tar tapes which default
at 126k for 8mm and 256k for 4mm.

Is it possible the byte order is reversed on Apollo tapes so FreeBSD's 
GNU tar can't make sense of it? I don't see a byte-order option in pax. 
For dd its "conv=swab".

To duplicate your tapes use tcopy(1) if you have two tape drives. Tcopy 
will figure out what block size is used, and refigure that block size 
with every block copied.

Best that I can tell there are several utilities floating around on the 
net named "ansitape". At least one of them is capable of storing a tape 
image on disk, and later restoring that image to tape with the same 
blocking as the original. At least that's what is claimed, I've not 
tried it but would like to have a utility that does that. Keep trying 
to get a "Round Tuit" at work, to enhance tcopy.

--
David Kelly N4HHE, dkelly@nospam.hiwaay.net
=====================================================================
The human mind ordinarily operates at only ten percent of its
capacity -- the rest is overhead for the operating system.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199807021344.IAA17009>