From owner-freebsd-current@FreeBSD.ORG Sun Jan 18 00:04:34 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 3126516A4CE for ; Sun, 18 Jan 2004 00:04:34 -0800 (PST) Received: from server.vk2pj.dyndns.org (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EB4D43D1F for ; Sun, 18 Jan 2004 00:04:32 -0800 (PST) (envelope-from peterjeremy@optushome.com.au) Received: from server.vk2pj.dyndns.org (localhost.vk2pj.dyndns.org [127.0.0.1])i0I84KPf000571; Sun, 18 Jan 2004 19:04:20 +1100 (EST) (envelope-from peter@server.vk2pj.dyndns.org) Received: (from peter@localhost) by server.vk2pj.dyndns.org (8.12.10/8.12.10/Submit) id i0I84KLt000570; Sun, 18 Jan 2004 19:04:20 +1100 (EST) (envelope-from peter) Date: Sun, 18 Jan 2004 19:04:20 +1100 From: Peter Jeremy To: Randy Bush Message-ID: <20040118080420.GA447@server.vk2pj.dyndns.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i cc: FreeBSD Current 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 08:04:34 -0000 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. Peter