FreeBSD blues... Tape drive... not even google knows why :(

Greg 'groggy' Lehey grog at lemis.com
Thu May 8 12:48:28 CST 2003


On Wednesday,  7 May 2003 at 14:59:51 +0930, Daniel A Moore wrote:
> Hello all... I have been trying to solve this problem for weeks and
> there doesn't seem anywhere on the net that can help.

You know about http://www.auug.org.au/mailman/listinfo/buga, right?  I
would have thought that would have been a more relevant list to send
this message to.

> I seem to be having a "little" trouble with my tape drive. I "aquired" a
> SONY AIT SDX-S300C tape drive and am trying to put it to use on my
> FreeBSD 4.4. I installed the SCSI card and that works, I have some
> mounted SCSI drives running off it. I have put all the jumpers to the
> positions that the Sony page says are for Unix... they don't say
> anything about FreeBSD in particular. I can access the tape drive
> through the mt command. I can rewind the tape, I can delete the tape.
> But here's where the trouble starts:
>
> dump -0u -b 512 -f  /dev/sa0 /home
>
> I found on the Sony site that the block size was meant to be 512 so I
> put it just in case (-b 512). However this outputs :
>
> DUMP: Date of this level 0 dump: Wed May 7 13:55:15 2003
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /home to /dev/sa0
> DUMP: bad sblock magic number
> DUMP: The ENTIRE dump is aborted.
>
> I read somewhere that FreeBSD only does dumps to entire devices... I
> didn't really believe this but I tried it anyway:
>
> dump -0u -b 512 -f  /dev/sa0 /
>
> DUMP: Date of this level 0 dump: Wed May 7 14:09:07 2003
> DUMP: Date of last level 0 dump: the epoch
> DUMP: Dumping /home to /dev/sa0

This doesn't appear to match the command you mention above.

> DUMP: mapping (Pass I) [regular files]
> DUMP: mapping (Pass II) [directories]
> DUMP: estimated 462375 tape blocks on 10.61 tape(s).
> DUMP: 0.11% done, finished in 0:00
> DUMP: dumping (Pass III) [directories]
> DUMP: dumping (Pass IV) [regular files]
> DUMP: Closing /dev/sa0
> DUMP: Change Volumes: Mount volume #2
> DUMP: Is the new volume mounted and ready to go?: ("yes" or "no")
>
> This process takes about 5 minutes to get to this point. Now this can't
> be right. I am using the SDX1-25C tape media and that has an
> uncompressed capacity of 25 GB! With hardware compression that's 50.
> Perhaps it's dumping data to the contents information portion of the
> tape or something. I don't know what's going on.

dump is stupid.

> I have read about someone getting it working by installing an MX
> driver but I have no idea what that is or even where to look for it.

What's an MX driver?

> So can anyone give me a little insight into what's going on or even
> just give me some ideas as to where to go to next? Apart from this
> using FreeBSD has been a dream.

The thing here is that end-of-medium handling on modern tapes is just
plain broken, so dump makes assumptions about how long the tape is.
They're based on much older tapes.  You have a number of options here.
From dump(8):

     -a      ``auto-size''.  Bypass all tape length considerations, and
             enforce writing until an end-of-media indication is returned.
             This fits best for most modern tape drives.  Use of this option
             is particularly recommended when appending to an existing tape,
             or using a tape drive with hardware compression (where you can
             never be sure about the compression ratio).

     -B records
             The number of kilobytes per output volume, except that if it is
             not an integer multiple of the output block size, the command
             uses the next smaller such multiple.  This option overrides the
             calculation of tape size based on length and density.

     -d density
             Set tape density to density.  The default is 1600BPI.

Note that default.

     -s feet
             Attempt to calculate the amount of tape needed at a particular
             density.  If this amount is exceeded, dump prompts for a new
             tape.  It is recommended to be a bit conservative on this option.
             The default tape length is 2300 feet.

These parameters are correct for the tapes used on VAXen 20 years
ago.  They give you a default capacity per tape of 46 MB, unless they
also make assumptions about tape gaps.

> Oh yeah and when I try a restore (just for the heck of it, I've never
> tried to complete the 10 tape series, as I don't have 10 tapes :( ):
>
> restore -if /dev/sa0
>
> It makes some whirring noise and the busy light goes on...
>
> (sa0:sym0:0:0): 65536-byte tape record bigger than supplied buffer
> tape read error: Input/output error
> May 7 14:23:29 testbed /kernel: (sa0:sym0:0:0): 65536-byte tape record bigger than supplied buffer
> May 7 14:23:29 testbed /kernel: (sa0:sym0:0:0): 65536-byte tape record bigger than supplied buffer

Yes, that's reasonable, since you've used the -b 512 option.  Again,
from the man page:

     -b blocksize
             The number of kilobytes per output block, except that if it is
             larger than 64, the command uses 64. (See the BUGS section.)  The
             default block size is 10.

BUGS

     Currently, physio(9) slices all requests into chunks of 64 KB.  There-
     fore, it is impossible to use a larger output block size, so dump will
     prevent this from happening.

This bug is in fact incorrect; physio(9) now does 128 kB.  Anyway, you
need to specify -b 64 to restore as well.

As others have observed, though, there are better choices.  On tape I
use tar, because the format is more portable.

Greg
--
Finger grog at lemis.com for PGP public key
See complete headers for address and phone numbers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://www.linuxsa.org.au/pipermail/linuxsa/attachments/20030508/04568205/attachment.bin


More information about the linuxsa mailing list