From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 13:12:48 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9505B16A4CE for ; Sun, 18 Jan 2004 13:12:48 -0800 (PST) Received: from amsfep17-int.chello.nl (amsfep17-int.chello.nl [213.46.243.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5EA743D31 for ; Sun, 18 Jan 2004 13:12:45 -0800 (PST) (envelope-from ronald-freebsd5@klop.yi.org) Received: from laptop ([24.132.246.115]) by amsfep17-int.chello.nl (InterMail vM.6.00.05.02 201-2115-109-103-20031105) with ESMTP id <20040118211244.GEMH24533.amsfep17-int.chello.nl@laptop> for ; Sun, 18 Jan 2004 22:12:44 +0100 To: FreeBSD Current References: <20040118080420.GA447@server.vk2pj.dyndns.org> Message-ID: From: Ronald Klop Content-Type: text/plain; format=flowed; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Date: Sun, 18 Jan 2004 22:12:37 +0100 In-Reply-To: <20040118080420.GA447@server.vk2pj.dyndns.org> User-Agent: Opera7.23/FreeBSD M2 build 518 X-Mailman-Approved-At: Mon, 19 Jan 2004 06:28:30 -0800 Subject: Re: rewinding a disk drive takes too long X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2004 21:12:48 -0000 On Sun, 18 Jan 2004 19:04:20 +1100, Peter Jeremy wrote: > On Sat, Jan 17, 2004 at 09:55:53PM +0000, Randy Bush wrote: >> dumping to a remote disk a la >> /sbin/rdump 0Luaf foo.bar:/backup/usr /dev/ad0s3g > ... >> DUMP: 99.54% done, finished in 0:01 >> DUMP: 101.28% done, finished in 0:-3 <<<<<<<<<======== >> DUMP: DUMP: 7473583 tape blocks on 1 volume >> >> that seems a long time to rewind a disk file :-) >> >> and it paused at 0:01 for at least five minutes > > [r]dump(8) provides a status report every 5 minutes. The '% done' > field is based on the initial estimate of how much data needs to be > written and the time field is an estimate of how until it reaches 100% > done based on the rate to date. If you're dumping an active > filesystem, it's possible that the initial size was an under-estimate > (if you look back, you'll probably find that it was about 3% less than > the 7473583 block actually dumped). At the time of the last report, > it had dumped 101.28% of the estimated volume and so estimated that > it reached 100% 3 minutes previously. Wouldn't snapshots solve this? -- Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/