From owner-freebsd-current@FreeBSD.ORG  Fri Apr 23 22:40:53 2004
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
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 30A2616A4CE; Fri, 23 Apr 2004 22:40:53 -0700 (PDT)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id C35BE43D66; Fri, 23 Apr 2004 22:40:52 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i3O5eA7E053079;
	Fri, 23 Apr 2004 22:40:14 -0700 (PDT)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200404240540.i3O5eA7E053079@gw.catspoiler.org>
Date: Fri, 23 Apr 2004 22:40:10 -0700 (PDT)
From: Don Lewis <truckman@FreeBSD.org>
To: kientzle@FreeBSD.org
In-Reply-To: <4089F79D.6040708@freebsd.org>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: current@FreeBSD.org
cc: julian@elischer.org
Subject: Re: Testing Tar (was Re: bad news for bsdtar..)
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Apr 2004 05:40:53 -0000

On 23 Apr, Tim Kientzle wrote:
> [Discussion moved to current@]
> 
> Bruce Evans wrote:
>> 
>> At least the -current version of tar skips reading the
>> data when it is writing to /dev/null.
> 
> A-ha!  That explains a few of the odd timings I've seen.
> I wonder why it does that?  (Other than to look good on
> benchmarks, of course. ;-)

This speeds up Amanda quite a bit.  Amanda will run tar with the
--totals option as well as other options to specify either full or
incremental backups multiple times for each file system that it backs
up.  It does this to plan the best mixture of full and incremental
backups.  If tar actually read the data from disk each time, the
planning phase would take a *lot* longer, and would thrash the disk a
lot more.