On Mon, 16 Jul 2012 09:04:31 -0500 (CDT) Robert Bonomi articulated: > > From owner-freebsd-questi...@freebsd.org Sun Jul 15 16:31:45 2012 > > Date: Sun, 15 Jul 2012 23:29:39 +0200 (CEST) > > From: Wojciech Puchar <woj...@wojtek.tensor.gdynia.pl> > > To: FreeBSD <freebsd-questions@freebsd.org> > > Subject: Re: fsck on FAT32 filesystem? > > > > > totally in error. SpinRite will attempt to read a damage sector > > > up to 2000 times and through different algorithms determine what > > > is most > > > > man dd > > > > conv=sync,noerror > > 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. -- Jerry ♔ Disclaimer: off-list followups get on-list replies or get ignored. Please do not ignore the Reply-To header. __________________________________________________________________ _______________________________________________ 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"