Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 15 Apr 96 18:21:35 MDT
From:      Greg Lehey <lehey.pad@sni.de>
To:        amir@neuron.net (Amir Y. Rosenblatt)
Cc:        freebsd-questions@FreeBSD.org
Subject:   Re: tar and restore problem
Message-ID:  <199604151622.SAA13642@nixpbe.pdb.sni.de>
In-Reply-To: <199604101417.KAA03610@pipe4.nyc.pipeline.com>; from "Amir Y. Rosenblatt" at Apr 10, 96 10:17 am

next in thread | previous in thread | raw e-mail | index | archive | help
>
> After bringing my machine up and running it for the better part of a
> week, I decided that I needed to reconfigure the disk partitions.  So I
> did a set of filesystem dumps to a 4mm DAT, but when I tried to do test
> restores of them, I got an error message ("Input/output error").  I tried
> about a dozen different sets of parameters but none of them, let me do a
> restore.  So, I tried using tar instead (I did my initial installation
> from tape, as well as having installed a bunch of the initial software
> that way).  I did some test tart and untars and they worked fine.  So, I
> crossed my fingers and did a "tar -cvf /dev/rst0 /" and 15 minutes later
> it finished.  I then went and reinstalled the machine from the 2.1
> install media (the same tape I used the first time) and prepared to
> restore the OS to the way it had been before the reconfig.  Howerver,
> when I attempted to untar it (using "tar -xvf /dev/rst0") I got the
> following error:
>
> st0: 65536-byte record too big
> tar: read error on /dev/rst0: Input/output error
>
> Then I got two console messages, both reading as follows:
>
> /kernel: st0 65536-byte record too big
>
> I attempted to list the contents of the tape, using "tar -tvf /dev/rst0"
> and that worked fine.  But I was still unable to untar the contents of
> the tape.
>
> OS-wise, when I did the backup I was running a 2.1R kernel on a -stable
> OS (I'd had some PPP problems with my -stable kernel which I had planned
> to deal with tonight and there had been no problems with the setup up to
> that point).  The tape drive is an HP SureStore SCSI-2 8 gig 4mm DAT
> drive.  My hard drives are Seagate ST32550W Baraccudah 2LPs (I have 2 of
> them).  I'm using an Adaptec 2940W as my SCSI-2 host adapter.  The
> machine itself is a P120, with an Asus motherboard, 32 meg of RAM and a
> Mach64 graphics card.
>
> I recompiled my kernel hoping that might help (couldn't hurt, as it
> brought it closer to the way I'd had the kernel set up originally), but
> there are still some differences between my current kernel and the
> original one.  The original one had the SCSI drives hardwired to their
> device files (i.e. SCSI device 0 was hardwired to sd0, etc).

This all sounds strange.  I assume that "SureStore" is a marketese
word for the HP C1533A.  You should be able to check that from the
messages printed on booting.  From your initial description I wasn't
100% sure that you were really backing up and restoring on the same
drive, but the rest seemed to indicate that you were.  If more than
one drive is involved, the rest of this message may not apply.

Basically, the message is telling you that your tape data is blocked
at 65536 bytes per blocks.  I don't really understand this, since you
didn't ask for that, and by default tar blocks with 20 "blocks" of 512
bytes, or 10240 bytes per block.  On the other hand, I've never used a
1533 on FreeBSD, and 64K blocks do make a lot of sense on HP DDS
drives (they're significantly faster like that), so it could be that
somebody has given you 64K blocks anyway.  The only thing I don't
understand is why 'tar t' works and 'tar x' doesn't.

In any case, try:

  tar xb 128 files ...

The 'b 128' tells tar to read blocks of 128 512-byte "blocks".  That
should work.  If it doesn't, let me know what it says.

------------------------------------------------------------
Greg Lehey                       LEMIS
grog@lemis.de			 Schellnhausen 2
Tel: +49-6637-919123		 36325 Feldatal
Fax: +49-6637-919122		 Germany



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604151622.SAA13642>