From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 8 08:23:58 2007 Return-Path: X-Original-To: freebsd-hackers@FreeBSD.ORG Delivered-To: freebsd-hackers@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD8D016A407 for ; Mon, 8 Jan 2007 08:23:58 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.freebsd.org (Postfix) with ESMTP id 4A34913C441 for ; Mon, 8 Jan 2007 08:23:57 +0000 (UTC) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (eryjgx@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.4/8.13.4) with ESMTP id l088Ng7p082553; Mon, 8 Jan 2007 09:23:47 +0100 (CET) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.4/8.13.1/Submit) id l088Nfqe082552; Mon, 8 Jan 2007 09:23:41 +0100 (CET) (envelope-from olli) Date: Mon, 8 Jan 2007 09:23:41 +0100 (CET) Message-Id: <200701080823.l088Nfqe082552@lurza.secnetix.de> From: Oliver Fromme To: freebsd-hackers@FreeBSD.ORG, dgilbert@dclg.ca, perryh@pluto.rain.com In-Reply-To: <45a1c260./gHVPL2TJkCotGTS%perryh@pluto.rain.com> X-Newsgroups: list.freebsd-hackers User-Agent: tin/1.8.2-20060425 ("Shillay") (UNIX) (FreeBSD/4.11-STABLE (i386)) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.1.2 (lurza.secnetix.de [127.0.0.1]); Mon, 08 Jan 2007 09:23:48 +0100 (CET) Cc: Subject: Re: dump reads more than restore writes? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-hackers@FreeBSD.ORG, dgilbert@dclg.ca, perryh@pluto.rain.com List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2007 08:23:58 -0000 perryh@pluto.rain.com wrote: > [...] > > Is dump reading substantially more than restore is writing? > > Quite possibly, esp. if the source disk is nowhere near full and/or > most of the files being handled are small. dump reads every inode > on the disk, including those which are unallocated, I don't think it does that. Why should it read inodes that are unallocated? It reads the directory tree of the file system, so it knows which inodes are allocated, and there's no reason to read anything beyond that. However, it is true that dump|restore is a slow way to copy a file system. It's much faster to mount it and then use something like "cd $SRC; find -d . | cpio -dump $DST", or cpdup (from ports/sysutils/cpdup), or even tar. If the file systems are the same size and nearly full, then dd(1) is probably the fastest way to copy it (but neither of them must be mounted, of course). If it's not nearly full, dd is inefficient because it simply copies the device without regard to what areas are actually unallocated to files. However, I think that there must be a bug in gstat when it displays 600 GB read to copy a 200 GB file system. dump(8) is inefficient, but not _that_ inefficient. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "anyone new to programming should be kept as far from C++ as possible; actually showing the stuff should be considered a criminal offence" -- Jacek Generowicz