Some info to fill in the gaps.. First, on unix/linux style systems.. ALL disk i/o goes through the device driver. On all modern systems, the bad-block info is handled on the disk drive itself. The driver never knows about bad blocks. The BIG difference between tar and dd comes from how they are used. Tar, is generally pointed at a file system file or directory, whereas dd is generally pointed at a block device node. For forensics work, 'more' metadata is preserved by gathering a dd image of the entire block device ( /dev/sda for example ) than by copying the cooked filesystem ( tar of /usr for example ). For example, "tar cvf /dev/tape /mountpoint" will only save the actual file and basic metadata for existing files. You will lose nice things like slack space at the end of files, usused inode information, slack space in inodes, empty space in the filesystem, etc etc. By creating a dd image of a filesystem (dd if=/dev/sda of=/dev/tape) you have nearly all the information available.. Basically, you have everything available from the drive except possible sideband information from the tracks themselves, as well as data that MIGHT have existed in blocks that went bad over the life of the drive. (and information in reserved blocks on the drive ) Odds are, you will never use any of this in a forensics case anyway.. Unless you work for a three letter government agency, in which case, you already know all of this. On Sun, 13 Oct 2002 15:35:37 -0700 (PDT) Alvin Oga <alvin.secat_private-Consulting.com> wrote: > > hi ed > > my understanding .. > - most ( 99% ) of disk ascess is done by "device drivers" > that writes/reads in 512bytes ( sectors ) > - the device drivers knows where allthe bad blocks are > > - when using tar, and any other app to write data, the > file is written and avoids the 'bad blocks" > > - dd on the other hand, is a bit-level copy, that includes copying > of "partition" info to the next drive... which drags along > the bad block data ... > dd if=/dev/hda of=/dev/hdb > > ( everything including partitions is copied over ) > > - but given todays manufacturing technology of disk drive platters, > i think most people have forgetten about "bad blocks" > > - most people also do NOT use "check for bad block option" on their > 40GB or 6)GB or 100GB drive which can takes 6-10 hrs even on a 1GHz > machine > - not sure what will happen if one didnt do "bad block checking" > during formatting right after fdisk'ing > > - i think, one day, someone will lose a block of data on that one > bad block that happen to be bad > > - most apps does NOT write data and read it back ?? > - that was the job of mke2fsck to format the drive and check it > - writes to disk can be 2x faster(?) if it wasnt "verifying" > ( just asume that the disk controller knows what to do, as opposed > ( to the application code that writes user data to the disks > > anyway.. so goes my limited understanding ... > tar(block/sector level apps ) vs dd(bit level apps ) type of apps > > c ya > alvin > > On Sun, 13 Oct 2002, Ed Carp wrote: > > > > -- most people assume that there is no bad block on the disks > > > when using DD to copy data > > > - if there is a bad block on the master, you copy > > > that to the clone > > > > Not true. IDE drives transparently remap bad sectors, so you'll not see a bad sector on an IDE drive unless the remap area is full, > > then the drive is toast anyway. > > > > Regardless, the disk driver will return an error to the application program if there is an error reading data, so it is not possible > > to copy a bad sector from one disk to another. > > -- > > Ed Carp, N7EKG http://www.pobox.com/~erc 214/986-5870 > > Licensed Texas Peace Officer > > Computer Crime Investigation Consultant > > > > Director, Software Development > > Escapade Server-Side Scripting Engine Development Team > > Pensacola - Dallas - London - Dresden > > http://www.squishedmosquito.com > > > > "The whole aim of practical politics is to keep the populace alarmed-- and > > thus clamorous to be led to safety-- by menacing it with an endless series > > of hobgoblins, all of them imaginary." > > -- H. L. Mencken > > > > > ----------------------------------------------------------------- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Oct 14 2002 - 07:53:24 PDT