On Mon, Jul 16, 2012 at 10:50 AM, Jerry <je...@seibercom.net> wrote: > > > > > This is *precisely* why dd is _grossly_inferior_ to > > professional-grade tools like Spinrite. > > > > With the settings the resident "infallible expert on everything" > > <*SNORT*> recommends, dd will make _one_ attempt to read each disk > > sector, going through the O/S's device driver code, and write out > > 'whatever it got', regardless of whether or not ane sort of > > read-error was signalled. This results in GUARANNTEED, > > *UNRECOVERABLE*, GARBAGE in the copy, _every_ place where a read > > error was encountered. This result can be marginally acceptable -- > > for 'first-cut' attempts at accessing 'easily recoverable' data on > > the disk. > > > > 'dd' is purely 'amateurville', however, when it comes to recovering > > =critical= data inside an 'unreadable' (by the O/S) disk block. > > > > > > Spinrite, and other professional-grade tools, run absolutely > > stand-alone, without the use of _any_ O/S drivers, or even BIOS > > code. Spinrite _directly_ programs the hard-disk-controller chip, > > can retrieve into memory _every_ bit -- including address-marks, > > sector framing, recorded ECC bits, and so on -- on a track, for > > analysis, can seek from an inner track, read the bits, then seek from > > an _outer_ track, and do another read. It can also do things like > > step the heads 'fractionally' off the track center, and read > > _there_. By doing these kinds of *very*low*level* operations, that > > are forbidden to any 'userland' task, by an O/S, tools like Spinrite > > can do a FAR BETTER job of extracting data from damaged disks. > > > > Professional-grade tools can also do things like 'pre-initialize' the > > I/O buffer _in_the_disk_itself_, with _different_ bit patterns on > > multiple read passes, They can thus find bitstrings that are (a) the > > 'prior data' in th buffer, (b) bits that are read consistently from > > the disk, and (c) bits that 'change value' from one read attempt to > > the next. This allows such tools to do a much better job of > > RECONSTRUCTING the actual data in the 'error' sector(s). > > > > > > "Make a copy, and work only on the copy" _is_ good advice for > > attempting 'simple' data recovery with tools that run in 'userland', > > under an O/S. When the 'simple' approach fails, or is insufficient, > > it is time to bring out the "big guns" -- things like Spinrite -- > > which -require- direct accesss to the original damaged disk. Since > > Spinrite, and similar tools, operate READ-ONLY on the disk -- which > > is *not* guaranteed if there is a general-purpose O/S in the wa -- it > > _is_ generally safe to let them access the damaged original. The > > problematic situation is where spinning up the drive causes -more- > > damage to the media.. > > +1 > > I use to keep SpinRite on a flash drive that I could easily carry with > me if needed. Of course that would require the machine to be worked on > to have the ability to boot from a flash drive. Unfortunately, not all > of them could. Fortunately, I almost never need an industrial strength > recovery product like SpinRite. It is nice to know it is available if I > do though.
SpinWrong is a scam, Gibson is a fraud, and this conversation is pure marketing gibberish. I thought most had overcome this credulity years ago. It appears I was mistaken. -- Adam Vande More _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"