Date: Tue, 26 Jun 2001 10:21:56 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Flemming Froekjaer <flemming@froekjaer.org> Cc: hardware@FreeBSD.ORG Subject: Re: Disk performance Message-ID: <20010626102156.G95583@gsmx07.alcatel.com.au> In-Reply-To: <3B37C156.CD4CE20C@froekjaer.org>; from flemming@froekjaer.org on Mon, Jun 25, 2001 at 03:55:18PM -0700 References: <3B37C156.CD4CE20C@froekjaer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001-Jun-25 15:55:18 -0700, Flemming Froekjaer <flemming@froekjaer.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010626102156.G95583>