The following reply was made to PR kern/2698; it has been noted by GNATS.
From: Bill Paul <email@example.com>
Subject: Re: kern/2698: scsi tape driver problem
Date: Sun, 9 Feb 1997 13:10:30 -0500 (EST)
Of all the gin joints in all the towns in all the world, Peter Mutsaers
had to walk into mine and say:
> $ dump 1af /dev/rst0 /dev/rsd1f
> $ restore tf /dev/rst0
> tape read error: Input/output error
> console output: st0: block wrong size, 64 blocks residual
What about if you force a particular block size with dump/restore:
% dump -b 126 1af /dev/nrst0 /dev/rsd1f
% restore -b 126 ivf /dev/nrst0
> Also, I can never read a dump with dd (dd if=/dev/rst0 bs=512 fails):
> $ dd bs=512 if=/dev/rst0 of=/dev/null
> dd: /dev/rst0: Input/output error
> 0+0 records in
> 0+0 records out
> 0 bytes transferred in 12.830684 secs (0 bytes/sec)
> console output: st0: 10240-byte record too big
> Although I did specify bs=512!
But it's telling you that the dumps were written with 512*20 byte blocks.
Try using dd with bs=10240 (or bs=20b, which is equivalent). In order to
get dump(8) to create a dump volume with 512 byte blocks, you'd have to
do 'dump -b1' (1*512). I'm pretty sure it doesn't do that by default, so
trying to read the dump back with dd using a 512 byte block size can't
> Note: using tar instead of dump does not cause such problems. So dump
> must do something special to the device that triggers the problem.
Could be dump and restore disagree on their default buffer sizes. Out
of force of habit, I always explicitly specify a block size with dump
and restore, except when running them through pipes to stdin/stdout.
-Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu
Work: firstname.lastname@example.org | Center for Telecommunications Research
Home: email@example.com | Columbia University, New York City
"It is not I who am crazy; it is I who am mad!" - Ren Hoek, "Space Madness"