From owner-freebsd-hackers Thu Nov 12 23:15:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA03051 for freebsd-hackers-outgoing; Thu, 12 Nov 1998 23:15:03 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from allegro.lemis.com (allegro.lemis.com [192.109.197.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA03043 for ; Thu, 12 Nov 1998 23:14:59 -0800 (PST) (envelope-from grog@freebie.lemis.com) Received: from freebie.lemis.com (freebie.lemis.com [192.109.197.137]) by allegro.lemis.com (8.9.1/8.9.0) with ESMTP id RAA27813; Fri, 13 Nov 1998 17:44:38 +1030 (CST) Received: (from grog@localhost) by freebie.lemis.com (8.9.1/8.9.0) id RAA27762; Fri, 13 Nov 1998 17:44:37 +1030 (CST) Message-ID: <19981113174437.E781@freebie.lemis.com> Date: Fri, 13 Nov 1998 17:44:37 +1030 From: Greg Lehey To: Matthew Dillon , Peter Jeremy Cc: hackers@FreeBSD.ORG Subject: Re: dump(8) very slow References: <98Nov13.154625est.40323@border.alcanet.com.au> <199811130602.WAA01141@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i xFrom: Greg Lehey In-Reply-To: <199811130602.WAA01141@apollo.backplane.com>; from Matthew Dillon on Thu, Nov 12, 1998 at 10:02:45PM -0800 WWW-Home-Page: http://www.lemis.com/~grog Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-41-739-7062 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thursday, 12 November 1998 at 22:02:45 -0800, Matthew Dillon wrote: >> partial blocks read as a multiple of fragsize). For a typical >> filesystem this means that dump never reads more than 8K at a time >> (and if there are lots of small files, the average read size will >> drop). This translates (at least for me) to dump throughputs (to >> /dev/null) of 500-1000KBps - slower than typical tape drives. > > My SCSI tests show that although the cpu overhead is greater doing > small block reads, you will not gain a bandwidth advantage doing > larger block reads verses two smaller reads if the small reads are > 8K or larger (or even 4K or larger). Other people testing IDE have > shown the same results. Have you been using the raw device? > 1K vs 8K makes a big difference, but 8K vs 16K does not. The disk's > lookahead read cache handles it just fine. That depends on the disks. Here's what my test disks (admittedly, not the newest) do: # dd if=/dev/rsd1a of=/dev/null bs=8k 41943040 bytes transferred in 110.037927 secs (381169 bytes/sec) # dd if=/dev/rsd1a of=/dev/null bs=16k 41943040 bytes transferred in 67.824404 secs (618406 bytes/sec) # dd if=/dev/rsd1a of=/dev/null bs=32k 41943040 bytes transferred in 46.672556 secs (898666 bytes/sec) > This is for linear reads, of course. If dump is seeking around, then > reading larger blocks might be beneficial to avoid a seek-back later on. It doesn't have to be dump doing the seeking. Greg -- See complete headers for address, home page and phone numbers finger grog@lemis.com for PGP public key To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message