Date: Fri, 23 Aug 1996 14:10:02 -0700 (PDT) From: J Wunsch <j@uriah.heep.sax.de> To: freebsd-bugs Subject: Re: bin/1522: dump/restore leading to corrupted files Message-ID: <199608232110.OAA13342@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR bin/1522; it has been noted by GNATS. 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. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199608232110.OAA13342>