From owner-freebsd-current@FreeBSD.ORG  Tue May 13 11:33:33 2003
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 04B6F37B401
	for <freebsd-current@freebsd.org>;
	Tue, 13 May 2003 11:33:33 -0700 (PDT)
Received: from mailbox.univie.ac.at (mail.univie.ac.at [131.130.1.27])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A034A43F75
	for <freebsd-current@freebsd.org>;
	Tue, 13 May 2003 11:33:31 -0700 (PDT)
	(envelope-from l.ertl@univie.ac.at)
Received: from [10.0.0.2] (adslle.cc.univie.ac.at [131.130.102.11])
	by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id h4DIX4uO088034;
	Tue, 13 May 2003 20:33:10 +0200
Date: Tue, 13 May 2003 20:33:03 +0200 (CEST)
From: Lukas Ertl <l.ertl@univie.ac.at>
To: Kirk McKusick <mckusick@beastie.mckusick.com>
Message-ID: <20030513202634.R612@korben.in.tern>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
cc: Martin Blapp <mb@imp.ch>
cc: freebsd-current@freebsd.org
Subject: dump -L broken
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2003 18:33:33 -0000

Hi Kirk,

I'm not sure if you care about this, but it seems that dump -L is
currently broken, in a way that a restore from such a dump gives errors
like "expected next file 9, got 7", and sometimes the resulting tree
differs from the original.

If you make a snapshot by hand with mksnap_ffs, mdconfig it and then dump
/dev/md0 there's no problem.

Could it be that the unlink call in dumps main.c (right after the snapshot
is created, which is probably there to not dump the snapshot file too)
could cause this problems?

regards,
le

--=20
Lukas Ertl                             eMail: l.ertl@univie.ac.at
UNIX-Systemadministrator               Tel.:  (+43 1) 4277-14073
Zentraler Informatikdienst (ZID)       Fax.:  (+43 1) 4277-9140
der Universit=E4t Wien                   http://mailbox.univie.ac.at/~le/