From owner-freebsd-bugs Wed Nov 15 13:32:08 1995 Return-Path: owner-bugs Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id NAA00338 for bugs-outgoing; Wed, 15 Nov 1995 13:32:08 -0800 Received: from irz301.inf.tu-dresden.de (irz301.inf.tu-dresden.de [141.76.1.11]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id NAA00319 for ; Wed, 15 Nov 1995 13:31:54 -0800 Received: from sax.sax.de by irz301.inf.tu-dresden.de (8.6.12/8.6.12-s1) with ESMTP id WAA24379; Wed, 15 Nov 1995 22:31:08 +0100 Received: by sax.sax.de (8.6.11/8.6.12-s1) with UUCP id WAA04684; Wed, 15 Nov 1995 22:31:08 +0100 Received: (from j@localhost) by uriah.heep.sax.de (8.6.12/8.6.9) id VAA08838; Wed, 15 Nov 1995 21:55:33 +0100 From: J Wunsch Message-Id: <199511152055.VAA08838@uriah.heep.sax.de> Subject: Re: Cannot interactively restore from a multivolume dump To: sysseh@devetir.qld.gov.au (Stephen Hocking) Date: Wed, 15 Nov 1995 21:55:33 +0100 (MET) Cc: bugs@freebsd.org Reply-To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) In-Reply-To: <199511150944.JAA17130@netfl15a.devetir.qld.gov.au> from "Stephen Hocking" at Nov 15, 95 07:44:26 pm X-Phone: +49-351-2012 669 X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Content-Length: 1089 Sender: owner-bugs@freebsd.org Precedence: bulk As Stephen Hocking wrote: > I then tell it to extract, starting with the last volume when it > prompts me for the volume number. As each volume is processing, it > mumbles something about rsyncing & skipping a few blocks, and only > takes a tiny fraction of the time that it took to write each tape > i.e. it doesn't seem to be writing the full tape. ANybody else > noticed this? I've succesfully been using it. It's okay that it doesn't read the entire tape in order to find that it hasn't to deal with just that particular volume (that's one of the big advantages of dump/restore actually!). It simply tracks all i-node numbers that it wants to restore, and all it has to do for any volume is to examine the first header on it, and see if there's any actual work on this volume. (It does always write based on i-node number ordering.) So the question is: why did it think that your files haven't been on *any* volume? -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)