dd(1)'ing raw disk devices

[Paul Evan Matz]

In article <89323.005700BACON at MTUS5.BITNET> BACON at MTUS5.BITNET (Jeffery Bacon) writes:
>Let's suppose I do the following: (In the hypothetical realm for now:)
>
>ctsee8(4)# /bin/dd if=/dev/rsd0c | rsh ctsee5 /bin/dd of=/dev/rsd0c
>
>(ctsee8 is a Sun 3/60 running SunOS 4.0.3 with a 327MB scsi; ctsee5 is
>a diskless 3/50 client of ctsee8, with a formatted 327MB scsi disk
>attached and configured, but not being used by the machine.)
>...

When you say "attached and configured", do you mean that:
 a) the diskless 3/50's kernel has been configured with an entry like:
	disk          sd0 at si0 drive 0 flags 0

 b) you have run format on the disk, at which time you defined the 
    partition layout, which is tranlated into the "disk label".  The
    partition layout must match the layout of the source disk for the
    data to be meaningful to the destination disk host.

 c) if you intend to use the disk for root and swap, you have also added
    the appropriate entry to the kernel config file (this is not required
    to be able to write to the disk, but would be if you eventally what
    to use it).  The example entry implies that partition "a" is used
    for the root partition, and partition "b" is used for swap.
	config        vmunix         root on sd0 swap on sd0


>...
>I know I am copying over the partition table; I can handle that. But what
>about the defect list? And mapped bad sectors? Or anything else important?
>

Once the disk really is "configured", using dd or any raw disk device
access utility will not "copy over the partition table".  The disk
label is used by the raw device to understand where the boundaries of
each partition is.  (You may very well corrupt an adjacent file system,
created via newfs, on a partition with existing data when writing to a
disk with a differnet partiton/label topology).

On a SCSI disk, each of the eight partitions has a starting SCSI
logical block address and length (Some may are not used, and are
set to 0 length).  The way these logical block addresses are specified
is by starting cylinder and number of cylinders.  You can look at a
disk's label info by using dkinfo:

dkinfo sd0
sd0: Emulex MD21 controller at addr 140000, unit # 0
1018 cylinders 8 heads 34 sectors/track
a: 16048 sectors (59 cyls)
   starting cylinder 0
b: 33456 sectors (123 cyls)
   starting cylinder 59
c: 276896 sectors (1018 cyls)
   starting cylinder 0
g: 87856 sectors (323 cyls)
   starting cylinder 182
h: 139536 sectors (513 cyls)
   starting cylinder 505


By convention, /dev/rsd0c happens to map onto the entire disk.  So if the
disk you want to "copy" is the same size, and has the same labeling
setup (exactly), then what you want to do will work, and the data should
be readable and usable, so long as the machines are the same architecture.
(You will have to modify some of the host specific files, like /etc/fstab,
/etc/rc.boot, etc...)

It might be faster to copy only the partitions you really want (no reason 
to copy sd0b, as it is swap).

Also, most SCSI disks handle the defect list/bad sectors transparently.
The sd driver just specifies the logical block address and transfer length
of the data it wants, the disk does the rest.  One really never knows the
relationship between physical sectoring on the disk and logical block address,
which is just as well.

The nitty-gritty details of using dd, specifying # of blocks and count,
still has me mystified, especially when dding between disks and tapes,
or pipes.  The tar/bar/dump/dd/rsh man pages have lots of interesting stuff
in them, but there seems to be much they infer (read between the lines, RBTL?)
If anyone out there has any tips on this, please jump right in!

Good Luck.
_____________________________________________________________
|Regards,                           One Campus Drive        |
|Paul Matz                          PPG Biomedical Systems  |
|914-741-4685                       Pleasantville, NY. 10570|
-------------------------------------------------------------
path ppgbms!moe!paul at philabs.philips.com