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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] data]$ sudo dd if=/dev/nst1 of=img.raw bs=16777215 dd: reading `/dev/nst1': Value too large for defined data type [EMAIL PROTECTED] 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