Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 13 Nov 1998 17:44:37 +1030
From:      Greg Lehey <grog@lemis.com>
To:        Matthew Dillon <dillon@apollo.backplane.com>, Peter Jeremy <peter.jeremy@auss2.alcatel.com.au>
Cc:        hackers@FreeBSD.ORG
Subject:   Re: dump(8) very slow
Message-ID:  <19981113174437.E781@freebie.lemis.com>
In-Reply-To: <199811130602.WAA01141@apollo.backplane.com>; from Matthew Dillon on Thu, Nov 12, 1998 at 10:02:45PM -0800
References:  <98Nov13.154625est.40323@border.alcanet.com.au> <199811130602.WAA01141@apollo.backplane.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981113174437.E781>