fsck on FAT32 filesystem?

Robert Bonomi bonomi at mail.r-bonomi.com
Mon Jul 16 14:03:22 UTC 2012

> From owner-freebsd-questions at freebsd.org  Sun Jul 15 16:31:45 2012
> Date: Sun, 15 Jul 2012 23:29:39 +0200 (CEST)
> From: Wojciech Puchar <wojtek at wojtek.tensor.gdynia.pl>
> To: FreeBSD <freebsd-questions at 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

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..

More information about the freebsd-questions mailing list