From owner-freebsd-questions@FreeBSD.ORG Mon Jul 16 17:03:37 2012 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2DD9106564A for ; Mon, 16 Jul 2012 17:03:37 +0000 (UTC) (envelope-from amvandemore@gmail.com) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id A37878FC0A for ; Mon, 16 Jul 2012 17:03:37 +0000 (UTC) Received: by pbbro2 with SMTP id ro2so11163822pbb.13 for ; Mon, 16 Jul 2012 10:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=VIvK1H3xeAsk05Aogzd0trngtrOgt93zqGEBvXI2yYw=; b=Ppp1iO8J4kIrvzZ40+IM8EsCjIAaPR0hAW6SZ4RwKxDMuyfyO9zyn0k6DHjajWVFPf WwobyqrZalS2cwSios6yLVwvwBfjOyoT3jdklG/CLWtkTPlK7s7k+9GoWESJoHkDt/ZP nixSdDHj8GHXMWRPW4n0NHfas4I8EXywF7aWdFm/MYBODIQFOJhjcJnRy85p8VRgTWqL ZlqRyqLX/mHK7d4fAnw1285FyL1gAxbBAwn9NjZT3DXrcgN6rJT+nm5WdvLvkJ8Z1hii LOIqB7ZX1xwIxtO2vCxphoYykvf8L7/ORSjt5PTrpU8aKCBRcYLMHgR4iaz3KWRSSMsD KA2Q== MIME-Version: 1.0 Received: by 10.68.201.195 with SMTP id kc3mr28743318pbc.33.1342458217446; Mon, 16 Jul 2012 10:03:37 -0700 (PDT) Received: by 10.68.227.132 with HTTP; Mon, 16 Jul 2012 10:03:37 -0700 (PDT) In-Reply-To: <20120716115022.68940af1@scorpio> References: <201207161404.q6GE4VrC001138@mail.r-bonomi.com> <20120716115022.68940af1@scorpio> Date: Mon, 16 Jul 2012 12:03:37 -0500 Message-ID: From: Adam Vande More To: FreeBSD Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: fsck on FAT32 filesystem? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 17:03:37 -0000 On Mon, Jul 16, 2012 at 10:50 AM, Jerry 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