Date: Mon, 16 Jul 2012 12:03:37 -0500 From: Adam Vande More <amvandemore@gmail.com> To: FreeBSD <freebsd-questions@freebsd.org> Subject: Re: fsck on FAT32 filesystem? Message-ID: <CA%2BtpaK0ZVpd1tMGN_iW5xsE5xZFwX3cSERHmWy6OzH9o=Dz-=g@mail.gmail.com> In-Reply-To: <20120716115022.68940af1@scorpio> References: <alpine.BSF.2.00.1207152329290.2631@wojtek.tensor.gdynia.pl> <201207161404.q6GE4VrC001138@mail.r-bonomi.com> <20120716115022.68940af1@scorpio>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jul 16, 2012 at 10:50 AM, Jerry <jerry@seibercom.net> wrote: > > > > > 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. SpinWrong is a scam, Gibson is a fraud, and this conversation is pure marketing gibberish. I thought most had overcome this credulity years ago. It appears I was mistaken. -- Adam Vande More
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BtpaK0ZVpd1tMGN_iW5xsE5xZFwX3cSERHmWy6OzH9o=Dz-=g>