Re: dd limit???

["Robert G. (Doc) Savage" <dsavage@peaknet.net>]

On Wed, 2011-06-08 at 01:15 -0400, Robert Citek wrote:
> On Tue, Jun 7, 2011 at 9:43 PM, Robert G. (Doc) Savage
> <dsavage@peaknet.net> wrote:
> > Four times I've tried to use a Coolmax IDE-to-USB2 adapter to dd a
> > binary image of /dev/sda2 to a bare-metal backup image file on my
> > server. Every time the process stalls at 104,329,363,456 bytes (97.2G --
> > it's a 120G Seagate Momentus 5400.2). I can't kill the dd process. I
> > can't even warm boot the server. Have to hit the hard reset to complete
> > shutdown.
> >
> > Once it stalls, /var/log/messages keeps repeating:
> >
> > Jun  7 20:37:05 lion kernel:
> > Jun  7 20:37:08 lion kernel: sdc: Current: sense key: No Sense
> > Jun  7 20:37:08 lion kernel:     Add. Sense: No additional sense
> > information
> >
> > dmesg shows similar status:
> >
> > sdc: Current: sense key: No Sense
> >    Add. Sense: No additional sense information
> >
> > Before pulling the disk and connectiving to the Coolmax, I had to boot
> > to rescue mode with an F13 installation disk to run e2fsck against that
> > second partition to make sure it was OK. No problems reported.
> >
> > Am I running into some kind of numeric limit with dd?
> >
> > --Doc Savage
> >  Fairview Heights, IL
> What OS, distro, version, and kernel version are you seeing this with?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=473017
>  
> Also, what's the full command you are running?
> 
> Regards,
> - Robert

Robert,

The machine I'm using is a fully updated RHEL5.6 server running 64-bit
kernel 2.6.18-238.12.1 released May 7. Using dd from
coreutils-5.97-23.el5_6.4, and dd_rescue from dd_rescue-1.23-1.el5. The
laptop drive is connected to the server via a Coolmax IDE-to-USB2
adapter and is detected as /dev/sdc.

# fdisk -l /dev/sdc
Disk /dev/sdc: 120.0 GB, 120034123776 bytes
255 heads, 63 sectors/track, 14593 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdc1   *           1          64      512000   83  Linux
Partition 1 does not end on cylinder boundary.
/dev/sdc2              64       14463   115658752   83  Linux
/dev/sdc3           14463       14594     1048576   82  Linux swap / Solaris

dd_rescue stalled last night in almost exactly the same place, at
104,329,379,840 bytes:

# dd_rescue /dev/sdc2 F14-32-rootfs.img
dd_rescue: (info) expect to copy 115658752kB from /dev/sdc2
dd_rescue: (info): ipos: 101883904.0k, opos: 101883904.0k, xferd: 101883904.0k
                   errs:      0, errxfer:         0.0k, succxfer: 101883904.0k
             +curr.rate:    16790kB/s, avg.rate:    16963kB/s, avg.load:  4.9%
             >------------------------------------.....<  88%  ETA:  0:13:32

Unfortunately there is no udev .rules file in RHEL5.6 corresponding to
the 60-persistent-storage.rules, so I can't apply Roman's fix. Given
that was FC10, I have to think the RHEL has been patched to fix that
problem.

It does appear to be a "prematurely hit the end of the drive" problem
where the Momentus' metadata doesn't accurately describe the drive
geometry. I'm uncertain about that, though, because fdisk correctly
reads the advertised full 120.0GB size. Also, there's a swap
partition /dev/sdc3 beyond the end of /dev/sdc2 I'm copying. The drive
has been running 32-bit F14 flawlessly for six months in a Thinkpad
laptop, and several earlier releases going back six or seven years.

I'm puzzled. I've never seen a raw utility failure like this. dd is a
standard forensic tool that's been used reliably for many years. This
application does a bit-by-bit copy of partitions and MBR for later bare
metal restoration, should the "yum update" method fail for F15.

--Doc


-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.