From owner-freebsd-hardware Wed Jan 12 16:46:15 2000 Delivered-To: freebsd-hardware@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 1782F15099 for ; Wed, 12 Jan 2000 16:46:12 -0800 (PST) (envelope-from ken@panzer.kdm.org) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id RAA93632; Wed, 12 Jan 2000 17:46:00 -0700 (MST) (envelope-from ken) Date: Wed, 12 Jan 2000 17:46:00 -0700 From: "Kenneth D. Merry" To: Peter Jeremy Cc: freebsd-hardware@FreeBSD.ORG Subject: Re: hardware Message-ID: <20000112174600.C93414@panzer.kdm.org> References: <387D0354.63159B8@ddsecurity.com.br> <72218.947717759@verdi.nethelp.no> <20000113124314.I5228@cs.waikato.ac.nz> <20000113125237.J5228@cs.waikato.ac.nz> <20000112170836.B93083@panzer.kdm.org> <00Jan13.112932est.40330@border.alcanet.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <00Jan13.112932est.40330@border.alcanet.com.au>; from peter.jeremy@alcatel.com.au on Thu, Jan 13, 2000 at 11:29:30AM +1100 Sender: owner-freebsd-hardware@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 13, 2000 at 11:29:30 +1100, Peter Jeremy wrote: > On 2000-Jan-13 11:01:20 +1100, "Kenneth D. Merry" wrote: > >dump is notoriously slow. > > I wouldn't say `notoriously', but I agree it is slower than it could be. > > >If a file-based backup is acceptable, you could probably get a lot better > >performance by going through the filesystem. > > I'm not so sure. My experiences are that something like tar is > significantly slower than dump (and will result is all the inodes > having their atime updated). Admittedly, this will depend on the > sizes and layout of the files. I was thinking more about bru, which seemed to be a fair bit faster than dump when I tried it out a year or two ago. tar may indeed be slower. > 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. Yep, that sounds right. > 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). If you do manage to speed up dump, you'd be a hero to pretty much anyone who uses it to do backups. :) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message