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

Mark Ovens mark at ukug.uk.freebsd.org
Mon Nov 20 18:42:37 GMT 2006


Matthew Seaman wrote:
> It's already in tar format, so no need to un-tar it.  Something like this:
> 
>     gzcat foobar.tgz | dd bs=10k of=/dev/nsa0
> 
> will write it straight to tape.  Note the 10kB block size shown is very
> 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 anyhow.
> 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.

Regards,

Mark




More information about the Ukfreebsd mailing list