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)
--------------enigB767A7C1A911454DBA0517E2
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=
y
>> 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=
ow.
>> 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.=

>>
>=20
> Thanks Matthew. The tape drive is a HP DAT drive (DDS3). When I was
> trying to find the block size I used
>=20
> mt -f /dev/sa1 status
>=20
> on a tape created using tar(1):
>=20
> tar cvf /dev/sa1 <filelist>
>=20
> and it returned the blocksize as 'variable':
>=20
> # 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
> #
>=20
> 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:
>=20
> -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.
>=20
> 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.

	Cheers,

	Matthew

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


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

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

iD8DBQFFYhb38Mjk52CukIwRCOVmAJ4knwsyPJBovolpGicYZmT+H4UFAQCfZoFX
LSU1R7GRQgg4HYyz+tqTdqo=
=gyml
-----END PGP SIGNATURE-----

--------------enigB767A7C1A911454DBA0517E2--




More information about the Ukfreebsd mailing list