Date: Mon, 16 Jul 2012 11:50:22 -0400 From: Jerry <jerry@seibercom.net> To: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: fsck on FAT32 filesystem? Message-ID: <20120716115022.68940af1@scorpio> In-Reply-To: <201207161404.q6GE4VrC001138@mail.r-bonomi.com> References: <alpine.BSF.2.00.1207152329290.2631@wojtek.tensor.gdynia.pl> <201207161404.q6GE4VrC001138@mail.r-bonomi.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Jul 2012 09:04:31 -0500 (CDT) Robert Bonomi articulated: > > 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.. +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. __________________________________________________________________
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120716115022.68940af1>