Date: Thu, 12 Nov 1998 22:02:45 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> Cc: hackers@FreeBSD.ORG Subject: Re: dump(8) very slow Message-ID: <199811130602.WAA01141@apollo.backplane.com> References: <98Nov13.154625est.40323@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
: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.
1K vs 8K makes a big difference, but 8K vs 16K does not. The disk's
lookahead read cache handles it just fine.
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.
I think it's worth messing around with the code. But beware that dump
checks inodes more then once during a dump to determine if the file
has changed, and does other similar junk... you may not be able to
safely cache read data.
:Is this approach worth the effort? I suspect this depends on how well
:associated sequential blocks of inodes correlate to associated groups
:of data blocks on disk - I don't know the answer to this.
:
:Since this amounts to a buffer cache (albeit with a special layout and
:replacement policy), would dump be better off going through the buffer
:cache (maybe with some extra system calls to help dump tell the buffer
:cache management software what it's doing - ala madvise(2))?
:
:(*) where `large' is as big as possible whilst keeping dump(8) and
: the buffer(s) resident.
:
:Peter
:--
:Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au
:Alcatel Australia Limited
:41 Mandible St Phone: +61 2 9690 5019
:ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
:
:To Unsubscribe: send mail to majordomo@FreeBSD.org
:with "unsubscribe freebsd-hackers" in the body of the message
:
Matthew Dillon Engineering, HiWay Technologies, Inc. & BEST Internet
Communications & God knows what else.
<dillon@backplane.com> (Please include original email in any response)
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?199811130602.WAA01141>