From owner-freebsd-hardware Mon Jun 25 17:22:14 2001 Delivered-To: freebsd-hardware@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id AEA0F37B406 for ; Mon, 25 Jun 2001 17:22:08 -0700 (PDT) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id KAA24183; Tue, 26 Jun 2001 10:21:59 +1000 (EST) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37640) with ESMTP id <01K57WKDDKPCVLRHGS@cim.alcatel.com.au>; Tue, 26 Jun 2001 10:21:58 +1000 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.1/8.11.1) id f5Q0Lvd83561; Tue, 26 Jun 2001 10:21:57 +1000 (EST envelope-from jeremyp) Content-return: prohibited Date: Tue, 26 Jun 2001 10:21:56 +1000 From: Peter Jeremy Subject: Re: Disk performance In-reply-to: <3B37C156.CD4CE20C@froekjaer.org>; from flemming@froekjaer.org on Mon, Jun 25, 2001 at 03:55:18PM -0700 To: Flemming Froekjaer Cc: hardware@FreeBSD.ORG Mail-Followup-To: Flemming Froekjaer , hardware@FreeBSD.ORG Message-id: <20010626102156.G95583@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <3B37C156.CD4CE20C@froekjaer.org> Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On 2001-Jun-25 15:55:18 -0700, Flemming Froekjaer wrote: >I tried to dump a file system to a DLT tape. >The tape is cable of 10MB/s but I only got about 1600 KB/s >To find out if it was the tape I tried to dump to /dev/null instead, but >i still only get 1665 KB/s Some time ago (mid-November 1998), I looked into dump (check out the thread `dump(8) very slow' in freebsd-hackers). The major problem with dump is that it reads the disk in filesystem-block (typically 8K) sized blocks (or less for frags) and doesn't attempt to merge adjacent reads. It also dumps files in inode order - accessing the disk in same order as the output blocks, rather than trying to sort the disk reads. At the time, I instrumented dump to get a record of physical disk accesses whilst dumping a couple of filesystems and did some experiments with re-ordering the reads, but never posted my results (I don't remember what the results were, but I didn't get a massive speed-up). Apparently, NetBSD's dump(8) has improved the buffering to get much better throughput. You might like to have a look - I haven't gotten around to it yet. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message