copying /dev/da0 with dd(1) to file: output differs

[Matthias Apitz]

El día Saturday, November 20, 2010 a las 04:19:48PM -0800, perryh at pluto.rain.com escribió:

> ...
> > What does this mean? Does not look like errors, in case of random
> > error it whould be more caotic, or?
> 
> Good question.
> 
> To help sort out whether it matters, what happens if you read the
> stick using dump(8) instead of dd (or mount it read-only and read it
> with tar)?  Either of those methods will read only the parts that
> are in use.

Good idea!

A dump is fine and gives more or less the same size as the dump which
was restored to the USB key:

# dump -0au -f reRead.dmp /dev/da0s1a
  DUMP: Date of this level 0 dump: Sun Nov 21 08:05:25 2010
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/da0s1a to reRead.dmp
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 3282758 tape blocks.
  DUMP: dumping (Pass III) [directories]
  DUMP: dumping (Pass IV) [regular files]
  DUMP: 56.62% done, finished in 0:03 at Sun Nov 21 08:14:18 2010
  DUMP: DUMP: 3287561 tape blocks on 1 volume
  DUMP: finished in 586 seconds, throughput 5610 KBytes/sec
  DUMP: level 0 dump on Sun Nov 21 08:05:25 2010
  DUMP: Closing reRead.dmp
  DUMP: DUMP IS DONE
current# ls -l reRead.dmp ~guru/usb9root.dmp 
-r--r--r--  1 guru  wheel  3351920640 12 nov 13:40 /home/guru/usb9root.dmp
-rw-r--r--  1 root  wheel  3366461440 21 nov 08:15 reRead.dmp

One could as well MD5 compare all files with find(1), but this is
perhaps a bit overkill...

I will buy a 2nd key and restore the dd(1)'ed file to it with dd(1)...

	matthias
-- 
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <guru at unixarea.de> - w http://www.unixarea.de/