chris@mimsy.UUCP (Chris Torek) (09/09/88)
In an article whose referent has been deleted by bogus news software, I wrote: >>`dd' can indeed do the trick, but not with the options you gave. ... >> dd bs=N >>and >> dd ibs=N obs=N >>have different meanings. In article <43200036@uicsrd.csrd.uiuc.edu> kai@uicsrd.csrd.uiuc.edu writes: >With NO options, dd just copies input to output. If you specify "bs=20b", or >"ibs=20b obs=20b", dd reads and writes 10240 byte blocks from input to >output. Sorry, but these two parameter settings are the same, except that >using "bs" to specify both input and output buffer sizes is more efficient, >since copying between buffers need not be done, unless you are doing ASCII to >EBCDIC conversions or some other type of data conversion. Not so. (Qualifier: in V7, 2BSD, 3BSD and 4BSD, at least.) I discovered this by checking the source code. Setting `bs' has the side effect of not only setting `ibs' and `obs' but also setting an internal flag called `fflag'. If fflag is not set, dd will re-block input to output, so that `dd ibs=N obs=N' guarantees that all output writes save the last will be N bytes long. If fflag is set, and no conversion is needed, then it does indeed avoid copying between buffers, *and in addition*, it writes as output blocks the number of bytes read with each `read' system call. For example, if I have a tape on drive 0 (as /dev/tape/0@1600) and one on drive 1 (as /dev/tape/1@1600), and the one on drive 0 has four tape records containing 512, 128, 1024, and 256 bytes, then the command dd if=/dev/tape/0@1600 of=/dev/tape/1@1600 bs=1024 produces on the tape on drive 1 four tape records containing 512, 128, 1024, and 256 bytes, while the command dd if=/dev/tape/0@1600 of=/dev/tape/1@1600 ibs=1024 obs=1024 produces on the tape on drive 1 two tape records containing 1024 bytes and 896 bytes respectively. You can experiment with tty input and output, which shares with tape drives the peculiar property that the number of bytes returned from a read syscall is not necessarily the number of bytes requested. Run $ dd bs=4 and type as input 1 2 3 ^D Note that the output appears intermingled: 1 1 2 2 3 3 0+3 records in 0+3 records out $ Now try $ dd ibs=4 obs=4 and type as input 1 2 3 ^D This time the output appears thus: 1 2 1 2 3 3D (this `D' is left over from the BSD tty driver ctlecho) 0+3 records in 1+1 records out $ This confirms that `dd bs=N' and `dd ibs=N obs=N' do different things. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
BACON@MTUS5.BITNET (Jeffery Bacon) (11/19/89)
I tried this on comp.unix.questions, but got a big zero, so I'll try it here instead. 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.) What I hope to end up with here is an exact copy of the first disk on the second. Sure, we could partition it ourselves and use dump/restore to do it all, but this seems quick, cheap, and just as effective. Question is, am I doing any harm to the disk in any fashion by doing this? 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? I will admit that my knowledge of disks and disk-type stuff is pretty small (being drawn from vague Sun manuals that seem not to have been out to teach disk stuff in the first place), so maybe the obvious won't be too terribly obvious to me. (btw, how can I remedy my lack of knowledge about disks in general? Pointers to books on disks and disk-related stuff would be greatly appreciated.) Thanks one and all. ------- Jeffery Bacon Computing Technology Svcs., Michigan Technological University bitnet: bacon@mtus5 uucp (alternate): <world>!itivax!anet!bacos
paul@ppgbms (Paul Evan Matz) (11/21/89)
In article <89323.005700BACON@MTUS5.BITNET> BACON@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@philabs.philips.com
del@thrush.semi.harris-atd.com (Don Lewis) (11/22/89)
In article <21427@ppgbms.UUCP> paul@ppgbms.UUCP (Paul Evan Matz) writes: >In article <89323.005700BACON@MTUS5.BITNET> BACON@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). > The disc label is apparently stored in the "a" partition. Copying the raw "a" partition from another disc will overwrite the label and partition information. I have actually had this happen to me. Also, this is why you are not allowed to swap to the "a" partition in SunOS 4.0.x (the ufs code knows not to overwrite the label but not the swap code). >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). I just did it this and it works. In my case, however, I only wanted to duplicate the "a" and "g" partitions. I wanted to change the allocations between some of the other partitions. After copying the "a" partition, I had to re-label the disk to get the partition sizes back to what I wanted. > >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 327 is an ESDI disc hung off a SCSI->ESDI controller. I don't think the defect list is handled transparently on this disk. Also, I think the defect list is stored at the end of the "c" partition, but is mapped out of the others by the driver. I'm not real sure of this info. I haven't run across any reliable documentation of this. > >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! This is how I did it. Boot MUNIX, partition and label the disk Boot miniroot echo 'address otherhost' >>/etc/hosts ifconfig stuff to set my address rsh otherhost -n 'dd if=/dev/rsd0a bs=8k' | dd of=/dev/rsd0a obs=8k relabel as necessary copy other partitions mount /dev/sd0a /a edit /a/etc/rc.boot and /a/etc/hosts, etc. reboot > >Good Luck. >_____________________________________________________________ >|Regards, One Campus Drive | >|Paul Matz PPG Biomedical Systems | >|914-741-4685 Pleasantville, NY. 10570| >------------------------------------------------------------- >path ppgbms!moe!paul@philabs.philips.com -- Don "Truck" Lewis Harris Semiconductor Internet (if you're lucky): del@semi.harris-atd.com PO Box 883 MS 62A-028 Internet (if not): del%thrush@trantor.harris-atd.com Melbourne, FL 32901 UUCP (works): rutgers!soleil!thrush!del Phone: (407) 729-5205