fsck on FAT32 filesystem?
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
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