On Mon, Feb 10, 2003 at 08:43:22AM -0500, Phillip Hofmeister wrote: > On Mon, 10 Feb 2003 at 01:24:29PM +0100, Alberto Cort?s wrote: > > cp, dd and every command use the system calls, and system calls use > > the drivers, and i am not sure the drivers don't modify "structure". > > dd, cat, etc. do modify the structure. One common way I rip an ISO is: > > cat /dev/cdrom > myfile.iso > > The geometry of the HD and the cdrom are almost certainly different.
They don't modify any "structure". There is no structure, just a linear array of bytes. The partition table says where on the disk the sub-arrays called partitions start and end. There are various ways of addressing this byte array, such as Cylinder/Head/Sector addresses and Linear Block Addressing. These are only used in the partiton table and in PC BIOS APIs. They have no relevance to anything other than fdisk and lilo (and the partition detection code in the kernel). The byte array that is a partition can of course be any sequence of bytes whatsoever, but usually partitions hold filesystems. Filesystems (AFAIK) only use relative offsets; e.g. an ext3 filesystem stores the free block list in terms of where the blocks are relative to the start of the partition, not in terms of CHS or LBA addresses. You can dd a filesystem from a partition into a file, and mount it with the loopback device, without modifying the data from the partition, and it works. (Somebody has probably written a filesystem that deals with absolute disk addresses, but I hope there aren't any like that in common use!) Hard drives don't store their size in the byte array that is accessable. They can report it (as when you run hdparm -I /dev/hdx) via a channel other than normal reads and writes. This is how fdisk can tell how big it should let you make your partitions, not by reading the size of the old partition table. (there won't be a part table on a new hard drive: they come filled with zero bytes (as would result from dd if=/dev/zero of=/dev/hdx)). Also note that CDROMs don't use partition tables. Thus, CDROMs don't have "geometry". Incidentally, the data on a CDROM is physically in one long spiral, like a vinyl record. The data is logically broken up into 2kB blocks, each with its own error correction data. (audio CDs use 2352B blocks, with less error correction or something...) The difference between dd and cp is that you can tell dd what block size to use. If you are writing to a flash device, cp (which reads 4kB, then writes 4kB, etc.) will take a lot longer than dd bs=32k. Why? (some) flash devices have a block size of 32kB, so you have to rewrite the whole block to modify any part of it. If you write in small chunks, you have to do several read-modify-write cycles, instead of just one write cycle. Hard drive block sizes are 512B, so cp vs. dd doesn't make a difference. (bigger block sizes results in fewer system calls, and probably lower CPU overhead, though. I usually use dd bs=1024k.) -- #define X(x,y) x##y Peter Cordes ; e-mail: X([EMAIL PROTECTED] , ns.ca) "The gods confound the man who first found out how to distinguish the hours! Confound him, too, who in this place set up a sundial, to cut and hack my day so wretchedly into small pieces!" -- Plautus, 200 BC -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]