From nik@guava.blueberry.co.uk  Wed Aug 21 10:04:01 1996
Received: from guava.blueberry.co.uk ([194.70.52.51])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id KAA07325
          for <FreeBSD-gnats-submit@freebsd.org>; Wed, 21 Aug 1996 10:03:58 -0700 (PDT)
Received: (from nik@localhost)
          by guava.blueberry.co.uk (8.7.5/8.7.3) id SAA01271
          Wed, 21 Aug 1996 18:03:57 +0100 (BST)
Message-Id: <199608211703.SAA01271@guava.blueberry.co.uk>
Date: Wed, 21 Aug 1996 18:03:57 +0100 (BST)
From: Nik Clayton <nik@blueberry.co.uk>
Reply-To: nik@blueberry.co.uk
To: FreeBSD-gnats-submit@freebsd.org
Subject: dump/restore leading to corrupted files
X-Send-Pr-Version: 3.2

>Number:         1522
>Category:       bin
>Synopsis:       dump | restore of filesystem corrupted files
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Aug 21 10:10:01 PDT 1996
>Closed-Date:    Fri Feb 21 14:47:29 PST 1997
>Last-Modified:  Fri Feb 21 14:48:19 PST 1997
>Originator:     Nik Clayton
>Release:        FreeBSD 2.1.0-RELEASE i386
>Organization:
>Environment:

	FreeBSD-Stable (kern.osrevision = 199306)

	3 SCSI disks
	  sd0 SEAGATE ST31051N 0284
	  sd1 FUJITSU M1606S-512 6406
	  sd2 MICROP 2210-09MQ1001901 HQ30

        Using the ncr0 controller

>Description:

	I've just added a new (internal) disk to my system. It became
	sd1, with the existing sd1 becoming sd2 (as shown above). 

	Now, sd2 contained /usr/local, and sd1 was empty. I wanted to
	move /usr/local on to sd1, freeing up sd2 (an external drive)
	for other things.

	So I did:

	    dump 0f - /usr/local | (cd /mnt/sd1/e; restore xf -)

	as restore(8) suggests (in single user mode).

	After whirring and chugging away for some time (this was about 
	700MB of data) the restore finished, with no error messages. 

	However, after making appropriate changes to fstab(5) and rebooting 
	the system, random binaries in /usr/local/bin would coredump 
	immediately.

	Using cmp(1) and md5(1) I was able to confirm that the new copies
	of files on sd1 differed from the originals still stored on sd2.

	After blowing this attempt away, I tried again, this time using

	    cd /usr/local
	    find . -name \* -print | \ 
		cpio -p -a --block-size=128 -d -m -V /mnt/sd1/e

	which, after about 2 hours (should have mounted the damn thing
	async!) completed succesfully. An md5 comparison between the
	two disks shows the files are now correct.

>How-To-Repeat:

	As above.

>Fix:
	
>Release-Note:
>Audit-Trail:

From: J Wunsch <j@uriah.heep.sax.de>
To: nik@blueberry.co.uk
Cc: FreeBSD-gnats-submit@freebsd.org
Subject: Re: bin/1522: dump/restore leading to corrupted files
Date: Fri, 23 Aug 1996 22:41:24 +0200 (MET DST)

 As Nik Clayton wrote:
 
 > 	So I did:
 > 
 > 	    dump 0f - /usr/local | (cd /mnt/sd1/e; restore xf -)
 > 
 > 	as restore(8) suggests (in single user mode).
 
 > 	Using cmp(1) and md5(1) I was able to confirm that the new copies
 > 	of files on sd1 differed from the originals still stored on sd2.
 
 Can you reproduce this behaviour?
 
 I've just tried it by copying my /var over to another disk.  I'm also
 using the ncr driver.  Except for the obvious mismatches:
 
 # find . -type f | while read fname
 > do
 > cmp -s /var/$fname $fname || echo "$fname mismatch"
 > done
 ./account/acct mismatch
 ./log/cron mismatch
 #
 
 ...everything worked fine.  This is some 40 MB of data, consisting of
 lots of files (it also contains my news server hierarchy).
 
 I have done this previously, and cannot remember it giving me
 corrupted data either, so i would not suspect dump or restore being
 broken.  If it's not a hardware problem (that is only triggered by the
 different usage pattern for dump/restore vs. tar), i would rather
 suspect it being a VM problem or something in this line.
 
 If you can reproduce it, can you please provide us with a partial
 hexdump of the differing regions?
 
 -- 
 cheers, J"org
 
 joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE
 Never trust an operating system you don't have sources for. ;-)
State-Changed-From-To: open->closed 
State-Changed-By: mpp 
State-Changed-When: Fri Feb 21 14:47:29 PST 1997 
State-Changed-Why:  
Mail to the originator bounces, and Joerg has previously 
stated that he was unable to duplicate the problem. 
>Unformatted:
