On Thu, 11 Mar 2004 at 2:52pm, Jonathan Dill wrote

> Hmm. Check also "mt status" to make sure the drive thinks that the 
> blocksize is "0" if not change it with "mt blksize". The files will be 
> perfectly fine with bs=16M. gzip and/or tar will probably give a warning 
> bitching about the nulls at the end, but it won't have any effect on the 
> restore, the files will still be intact.

mt agress that the blocksize is variable:

SCSI 2 tape drive:
File number=4, block number=0, partition=0.
Tape block size 0 bytes. Density code 0x32 (no translation).
Soft error count since last status=0
General status bits on (85010000):
 EOF WR_PROT ONLINE IM_REP_EN

But dd doesn't seem to like my suggestions for blocksize:

[jlb@newhope data]$ sudo dd if=/dev/nst1 of=img.raw bs=16M
dd: reading `/dev/nst1': Invalid argument

OK, so 16M is technically bigger than the stated limits, so:

[jlb@newhope data]$ sudo dd if=/dev/nst1 of=img.raw bs=16777215
dd: reading `/dev/nst1': Value too large for defined data type
[jlb@newhope data]$ sudo dd if=/dev/nst1 of=img.raw bs=8M      
dd: reading `/dev/nst1': Value too large for defined data type

But 4M works.  ??  And to add insult to injury, that's going at about 
70K/s.  

> In some desparate cases in the past, where some mung brain had data on 
> Sony Video 8 tapes (!) I ended up mucking around with "mt blksize" and 
> just using "cat" to try to grab the stuff off the tape without any 
> blocking, crazy as that sounds, but that was also on SGI IRIX with 
> Exabyte 820 "Eagle" drives. It was a pain, and there were loads of 
> errors, but I got most of the data off the tapes.

That sounds... fun.

-- 
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University