From owner-freebsd-current  Tue Sep 16 01:26:19 1997
Return-Path: <owner-freebsd-current>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.7/8.8.7) id BAA10673
          for current-outgoing; Tue, 16 Sep 1997 01:26:19 -0700 (PDT)
Received: from mailbox.uq.edu.au (zzshocki.slip.cc.uq.edu.au [130.102.221.173])
          by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA10658
          for <current@freebsd.org>; Tue, 16 Sep 1997 01:26:11 -0700 (PDT)
Received: from bloop.craftncomp.com (localhost.craftncomp.com [127.0.0.1]) by mailbox.uq.edu.au (8.8.7/8.6.12) with ESMTP id SAA01105; Tue, 16 Sep 1997 18:29:41 +1000 (EST)
Message-Id: <199709160829.SAA01105@mailbox.uq.edu.au>
X-Mailer: exmh version 2.0zeta 7/24/97
To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch)
cc: current@freebsd.org
Subject: Re: restore seems to be misbehaving 
In-reply-to: Your message of "Tue, 16 Sep 1997 01:43:22 +0200."
             <19970916014322.SQ08928@uriah.heep.sax.de> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 16 Sep 1997 18:29:40 +1000
From: Stephen Hocking <shocking@mailbox.uq.edu.au>
Sender: owner-freebsd-current@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

> As Stephen Hocking wrote:
> 
> > I was just bitten by this too - repartitioned my hard drive and lost a few 
> > files when restoring my /usr/src fs. I'm running with an NCR 810 also. I'll 
> > keep the dd trick in mind. The command used to back things up with a large 
> > number of QIC-150 tapes was "dump Obf 120000 /dev/rst0 /usr/src". Most
> > puzzling.
> 
> Uhh -- but QIC 150 tapes (you are using them up to 120 MB only
> actually) are in a *totally* different boat than the original posting.
> They are fixed-length blocking with 512 bytes per tape block.  They
> always *must* work, or something is royally screwed.  restore will
> probably claim the tape block size were 10 KB or even 32, but that
> doesn't matter: if it issues a read(2) with this blocksize, the kernel
> should read as many tape blocks as required to satisfy the request.
> 
> Variable-length blocking tapes are vastly different in their
> behaviour.
>
Well, that's quite correct, but the bug exhibited exactly the same symptoms 
(although I've yet to run ktrace to see whats happening). I think that there's 
something screwy happening, particularly on tape devices been used repeatedly 
with little or no pause

	Stephen