26 Apr
2006
26 Apr
'06
9:16 a.m.
At 08:15 PM 4/25/2006 -0400, Brad Parker wrote:
By "intact", I mean that the bits on the destination drive (at least
the first 40GB) match those which are on the source drive, identically.
Apparently it is a mechanism which allows the use of the underlying
hardware's DMA capabilities to do the transfers, or at least that is
my impression.
Yes, sorry about the confusion here. I initially attempted to use
the /dev/rwd0a and /dev/rwd1a devices which would normally be the
first partition on the drive (if it were partitioned). I did this
after trying to use the 'c' partition, which on all of the platforms
which I used in the past designated the "whole" drive. After some
searching and responses from others on another list, I discovered
that on the PC the 'd' partition represents the "whole" drive and
that is what I used.
An update on my current results is that using NetBSD on the raw
device was only slightly better than my results with linux. I am
guessing that this is due to a difference in where the copy terminated
at the end of the source drive due to a difference in cylinder/block
alignment or something. As of yet, neither method has produced the results
that I am looking for.
I thought that the IDE drives these days were just a logical stream
of blocks and that disk geometry was no longer a consideration. A
reply on this thread by JBG seems to confirm this, but perhaps there
is still some sort of translation going on due to the difference in
sizes of these two disks? I have noted that the 40GB disk is LBA
and the 100GB disk is LBA48.
After trying the G4U utility suggested by John, which is really just
a nicely wrapped NetBSD boot with some simple tools that utilize
'dd' and such, it looks like my problem is that the 40GB drive has
some uncorrectable data errors in the middle of the disk and these
have been stopping the copy prematurely. As the PC screen does not
allow scrollback and is only a small number of lines I had not
gathered that the completions were short and due to data errors
rather than just errors due to reaching the end of the media and
I was too lazy until now to work harder to understand what was really
going on.
So it would seem that both linux and NetBSD are both working similarly.
In order to attempt to copy as much of the data as possible without
a huge amount of human interaction, looking for errored blocks and
copying around them, I tried using the 'dd' command with the
'conv=noerror'
option under both the NetBSD and G4U systems and found that the option
was disabled. Fortunately when I booted the linux system and tried this
option, it did not complain. So the disk copy is underway again as I
type this and hopefully this time it will complete the entire copy
minus some bad blocks...
--tom
Tom Uban wrote:
Because there aren't any raw disk devices, at least not by default
and my google searches on the subject confirmed this. Of course as
this thread has discussed, the meaning of raw I/O and the reasons
for it vary, so I'll clarify.
I am copying a 40GB disk to a 100GB disk and when finished, would
like to have the first 40GB of the 100GB disk match the original
40GB disk, bit for bit.
Neither disk has any DOS, Windows, NT, Un*x, or Linux data structures
present, so no partition information, MBR data structures, etc.
To my amazement, I discovered
that linux does not have a raw disk I/O capability by default.
I'm not sure how you came to that conclusion, but if you met me
at a cocktail party I'd bet you a steak dinner that it did,
in fact, have raw i/o and dd should work to copy from one drive
to another. There are issues with ide disks, of course, and what
"raw i/o" means.
Others here can, I'm sure, speak more cogently but the issue surrounds
what linux things block "n" and how that maps to a particular
cylinder/head/sector on the disk and if linear block addressing is used
or not.
Yes. By "raw I/O", I was meaning that I don't want any interpretation
of the disk as a file system, etc. Under Un*x, the block device typically
requires that the disk be initialized with a filesystem, the disk be
mounted, etc. The raw device provides access to the disk without any
of this and allows the disk to be initialized with a partition table
and filesystem...
But with care you can certainly dd one disk to another.
I've done it
many times. You can also dd one disk to a file. I do that all the
time. And then I dd it back to a disk of the same type and it works
fine.
In years past, on non-PC platforms, I too have done this without any
difficulty. I believe that the heritage of the PC is throwing a wrench
into the works.
I tried using
the block devices, but the resulting copy was
not intact.
I don't know what "not intact" means. You may have not use the "whole
disk" raw device. If you used a partition device you won't get the
whole disk. It depend on what version of the kernel you used. 2.2?
2.4? 2.6? typically something like "/dev/hda" or
"/dev/hdb" will give you the
whole disk.
When I did the copy under linux, I used /dev/hda and /dev/hdb as you
describe. Under NetBSD, I used /dev/rwd0d and /dev/rwd1d. Note that
the linux /dev/hda device entry is a "block" device and the NetBSD
/dev/rwd0d device entry is a "raw" (or character) device. As an old
Un*x kernel developer, this is what I meant by "raw I/O" -- sorry
for any confusion.
After doing a
bit of searching, I discovered that
there is some sort of rawio extension which allows a raw device
to be associated with a block device, but it also said that dd
would not work with this raw device due to buffer alignment
issues vs. DMA. Go figure...
rawio is something else. My second
attempt was with a NetBSD 3.0 install CD, exiting to
the shell and trying dd from rwd0a to rwd1a. I know that back
in the dark ages, this was possible, but apparently in these
modern times things have changed. When I try to do this I receive
a read only error on the /dev/rwd1a device
you're using a parition device again. you got the raw character
device "rxxx" but wd1a is not the whole disk. I'm guessing but
I bet /dev/rwd1 might be.