Heh. I've never used strace, but after trying it out the thought of running it on a 60GB dd transfer gives me The Fear...I can't tell whether there's a way to have it display only syscall failures. I will install the latest coreutils, though.
Jim Meyering wrote:
Ernie Limperis <[EMAIL PROTECTED]> wrote:I had a strange problem with an apparent silent failure of dd to clone a Windows-partitioned disk yesterday. Environment: Ubuntu Linux, kernel 2.6.20-16-generic #2 SMP AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 1G ram dd version 5.97 Disks: Source: Seagate 60GB, about five years old, /dev/hdc Target: Western Digital 80GB, new OEM., /dev/hdd both IDE on a VIA controller (Asus M2V-TVM motherboard, chipset = K8M890/VT8327R Plus) Source Partition Table: something like this /dev/hdc1 * 1 1530 SFS /dev/hdc2 1530 <end of disk> Win95 LBA /dev/hdc5 # /dev/hdc6 # all Extended partitions, type SFS /dev/hdc7 # roughly equal sized at 10GB /dev/hdc8 # Command: dd if=/dev/hdc of=/dev/hdd conv=notrunc,noerror bs=32768 # also occured with bs=4096 Behavior: On multiple attempts, dd copied as far as hdc6 then exited with no error, reporting the full 60GB copy. fdisk on the target showed hdd7 as taking up the rest of the disk with an "empty" device type. Read errors appeared at roughly 30 GB because of bad sectors on the source, but the copy process continued as documented. Partition-by-partition dd worked fine (except for the read errors on one partition).Thanks for the report. If you can reproduce it while running via strace, and the strace output shows that there is a syscall failure, yet dd still doesn't report any problem, then *that* would be a bug: strace -o /tmp/strace dd if=/dev/hdc of=/dev/hdd conv=notrunc,noerror bs=32768 Even if you find a problem that way, I suggest you get a newer version of dd and retry with that one. The latest stable release is coreutils-6.9.
-- ============================================== Ernie Limperis 510-525-8801 [EMAIL PROTECTED] cell 510-682-6373 ============================================== _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
