Piping output of tar(1) into another tar(1) command

Matthew Seaman m.seaman at infracaninophile.co.uk
Mon Nov 20 20:58:25 GMT 2006

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: quoted-printable

Mark Ovens wrote:
> Matthew Seaman wrote:
>> It's already in tar format, so no need to un-tar it.  Something like
>> this:
>>     gzcat foobar.tgz | dd bs=3D10k of=3D/dev/nsa0
>> will write it straight to tape.  Note the 10kB block size shown is ver=
>> common with most tape hardware, but YMMV if you have a very weird tape=

>> drive.  You might even get away with entirely the wrong blocksize anyh=
>> After you've written it to tape use:
>>     mt -f /dev/nsa0 rewind
>>     tar -tvf /dev/nsa0
>> to verify that what was written to tape is readable and in good shape.=

> Thanks Matthew. The tape drive is a HP DAT drive (DDS3). When I was
> trying to find the block size I used
> mt -f /dev/sa1 status
> on a tape created using tar(1):
> tar cvf /dev/sa1 <filelist>
> and it returned the blocksize as 'variable':
> # mt -f /dev/sa1 status
> Mode      Density              Blocksize      bpi      Compression
> Current:  0x25:DDS-3           variable       97000    DCLZ
> ---------available modes---------
> 0:        0x25:DDS-3           variable       97000    DCLZ
> 1:        0x25:DDS-3           variable       97000    DCLZ
> 2:        0x25:DDS-3           variable       97000    DCLZ
> 3:        0x25:DDS-3           variable       97000    DCLZ
> ---------------------------------
> Current Driver State: at rest.
> ---------------------------------
> File Number: 0  Record Number: 0        Residual Count 0
> #
> I'm guessing that the reason for the variable block size is specific to=

> the hardware settings (DIP switches) since tar(1) implies 10k blocks
> unless specified otherwise:
> -b blocksize
>       Specify the block size, in 512-byte records, for tape drive I/O.
>       As a rule, this argument is only needed when reading from or
>       writing to tape drives, and usually not even then as the default
>       block size of 20 records (10240 bytes) is very common.
> I was always under the impression that tape device *had* to use fixed
> block sizes.

Actually, the variable block size on the tape is because you've got
hardware compression turned on, and the variation is due to how well
the drive can compress the input stream sent to it.  The input is
divided into equally sized blocks before compression.

Given that the drive will be dividing its input stream into chunks,
buffering up those chunks and compressing each buffer-full before
writing it to the tape, then it doesn't really matter too much what
size you use in the dd(1) line -- you should get a usable tape image
with anything reasonable.  However dd defaults to doing IO in 512byte
blocks, and you'll make the whole process a tad more efficient by
upping the block size so you're doing fewer but larger writes to the
tape device.



Dr Matthew J Seaman MA, D.Phil.                       7 Priory Courtyard
                                                      Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey         Ramsgate
                                                      Kent, CT11 9PW

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG v1.4.5 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org



More information about the Ukfreebsd mailing list