Date: Mon, 16 Jul 2012 09:04:31 -0500 (CDT) From: Robert Bonomi <bonomi@mail.r-bonomi.com> To: freebsd-questions@freebsd.org Subject: Re: fsck on FAT32 filesystem? Message-ID: <201207161404.q6GE4VrC001138@mail.r-bonomi.com> In-Reply-To: <alpine.BSF.2.00.1207152329290.2631@wojtek.tensor.gdynia.pl>
next in thread | previous in thread | raw e-mail | index | archive | help
> From owner-freebsd-questions@freebsd.org Sun Jul 15 16:31:45 2012 > Date: Sun, 15 Jul 2012 23:29:39 +0200 (CEST) > From: Wojciech Puchar <wojtek@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..
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201207161404.q6GE4VrC001138>