From owner-freebsd-questions@FreeBSD.ORG Mon Feb 3 13:13:14 2014 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2D8DB94 for ; Mon, 3 Feb 2014 13:13:14 +0000 (UTC) Received: from wonkity.com (wonkity.com [67.158.26.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 72F3E1743 for ; Mon, 3 Feb 2014 13:13:14 +0000 (UTC) Received: from wonkity.com (localhost [127.0.0.1]) by wonkity.com (8.14.7/8.14.7) with ESMTP id s13DDBlL025316; Mon, 3 Feb 2014 06:13:11 -0700 (MST) (envelope-from wblock@wonkity.com) Received: from localhost (wblock@localhost) by wonkity.com (8.14.7/8.14.7/Submit) with ESMTP id s13DDA7b025313; Mon, 3 Feb 2014 06:13:11 -0700 (MST) (envelope-from wblock@wonkity.com) Date: Mon, 3 Feb 2014 06:13:10 -0700 (MST) From: Warren Block To: Matthias Apitz Subject: Re: dump(8) && -b option In-Reply-To: <20140203074405.GA10184@sh4-5.1blu.de> Message-ID: References: <20140203074405.GA10184@sh4-5.1blu.de> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (wonkity.com [127.0.0.1]); Mon, 03 Feb 2014 06:13:12 -0700 (MST) Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 13:13:14 -0000 On Mon, 3 Feb 2014, Matthias Apitz wrote: > > Hello, > > Last weekend I was playing around with the dump options to improve the > dump speed to my external USB drive. I tried using the -b option to > increase the blocksize of the written junks: > > # dump -0auL -b 100 -f - /usr > ... > DUMP: finished in 40 seconds, throughput 7485 KBytes/sec > > # dump -0auL -b 10 -f - /usr > ... > DUMP: finished in 70 seconds, throughput 4274 KBytes/sec > > with -b 1000 the dump hangs forever: > > # dump -0auL -b 1000 -f - /usr > ... > DUMP: dumping (Pass III) [directories] > (hangs) > > on of its child is doing this where fd 3 is the device to be backed up: > > pread(0x3,0x28809000,0x1000,0x89909000,0xa5,0xbfbfcc88) ERR#5 'Input/output error' > pread(0x3,0x28809000,0x1000,0x89909000,0xa5,0xbfbfcc88) ERR#5 'Input/output error' > pread(0x3,0x28809000,0x1000,0x89909000,0xa5,0xbfbfcc88) ERR#5 'Input/output error' > pread(0x3,0x28809000,0x1000,0x89909000,0xa5,0xbfbfcc88) ERR#5 'Input/output error' > pread(0x3,0x28809000,0x1000,0x89909000,0xa5,0xbfbfcc88) ERR#5 'Input/output error' > > Why is this? Don't know, but I remember searching and finding reports of problems with -b values larger than 64. Those reports are years old, and unfortunately I can't find them now. > Maybe the best is doing the write to the disk with dd(1), for example > with > > # dump -0auL -f - /usr | dd bs=8m > /dev/da0s1a/usr.dmp Could make for interesting benchmarks. My guess is that the benefits would taper off after a smaller buffer size than that. Using -b64 at the same time would probably help reduce overhead.