[ale] 4mm problem.

Bob's Bulk mail transam at cavu.com
Thu Nov 21 23:17:03 EST 1996


Robert L. Harris wrote:

> Arnold D. Robbins wrote:
> > 
> > > I have a 4mm at home on my PC and want to recover the data.  When I do a
> > > "dd conv=swab if=/dev/st0 | tar -xvf - <filename>"   I get an "Incorrect
> > > Block Size".  Anyone have any clues as to how to remedy this?  I tried
> > > setting ibs to different values but that is either wrong or I couldn't
> > > get the right value.
> > 
> > With tar, you shouldn't need to do any byte swapping, unless SGI's tar
> > is REALLY REALLY broken.

> It is.

I don't know about now, but it certainly was not broken when I did the
original port of tar to SGI for SGI.

UNlike cpio, tar's header format does not suffer from byte-ordering
problems so a "dd conv=swab" should never be necessary.

It would be helpful to know if /dev/st0 is a character or blocked device
and ditto for the device on the SGI that you made the tape from.

If they are both blocked devices (which I suspect they are)
then the following should work:

	tar -xvbf 1 /dev/your_dev filename

If they are both character devices then your blocking factor should match
the blocking factor used to write the tape.  NOTE that the default blocking
factor that tar uses (when the -b flag is omitted) varies between different
vendors.  The most common factors are 20 and 1.

To take enjoy the performance advantages of the streaming QIC tapes at
that time, the original SGI tar program used a very large blocking factor.
I believe I used 100 if not specified by the user (with the -b flag).
(The blocking factor is in units of 512 bytes so "-b 20" is 10kb blocks.)

Tar uses this count as the size of each read or write request.  Unless
the -B flag is given, if a read comes up short (during extraction) an
error exit is taken.

Internally, tar does things in chunks of 512 bytes.  This is important
to remember.  When reading from a file that does not have fixed blocks
with tar, you can use any blocking factor that divides into the blocking
factor used to create the tar file.

When reading buffered devices (blocked devices)
or disk files, the total number of 512-byte blocks written must be
divisable by the blocking factor used to read the file.

This is guaranteed if the reading blocking factor divides into the
writing blocking factor.

In other words if a tar file is created via:

	tar -cvbf 12 foo.tar something

any of the following could extract it:

	tar -cvbf  1 foo.tar something
	tar -cvbf  2 foo.tar something
	tar -cvbf  3 foo.tar something
	tar -cvbf  4 foo.tar something
	tar -cvbf  6 foo.tar something
	tar -cvbf 12 foo.tar something

Additionally, if 35 of these 12*512 byte records are written then any
blocking factor that divides into 12*35 can be used, including 5 and 7.


When writing to variable-blocked devices such as 9-track mag tape with
the raw (character) device, the physical blocks on the tape are the size of
each write request.  If the respective read request is smaller then the
rest of each physical block is thrown away without notice.  If the respective
read request is larger, the read will return a count matching that which
was used to write the block, along with the block's data.  Tar pads the last
record to the specified size.


Thus there are two problems to resolve.  The first is getting the data off of
the tape and the second is satisfying tar's reads.

You can use dd to get the data off of a variable-blocked device and then
pipe that to tar with a blocking factor of 1.  For example, if the tape
was written with a blocking factor of 100 (and your tar won't accept this
large a blocking factor) then the following should work:

	dd if=/dev/your_device bs=51200 | tar -xvbBf 1 - something

The 'B' flag may not be necessary in the above case, though the
buffering through a pipe can vary.  The following is even safer:

	dd if=/dev/your_device bs=51200 > tmp
	tar -xvbf 1 tmp something

You might even try the following if you're still having trouble:

	dd if=/dev/your_device bs=51200 > tmp
	od -c tmp | less

If the data is not confidential you could even send me the first few blocks
and I might be able to figure it out:

	dd if=/dev/your_device bs=51200 count=1 | uuencode 51200 | \
	mail -s 51200 bob at cavu.com

	dd if=/dev/your_device bs=10000 count=1 | uuencode 10000 | \
	mailx -s 10000 bob at cavu.com

Bob Toxen
bob at cavu.com
transam at cavu.com [ALE]
http://www.mindspring.com/~cavu
Fly-By-Day Consulting, Inc.
"Venimus, Vidimus, Dolavimus" (We came, we saw, we hacked)






More information about the Ale mailing list