Re: [Bug-ddrescue] Suggestion / feature request - bad head mapping

[Scott Dwyer]

I don't know of any tools that can create a domain file for targeting 
heads. It is too dynamic to be done in any easy way. Professional tools 
use special vendor specific commands to map heads. But I do know of a 
tool that can help target things in the NTFS filesystem.

There is ddrutility, which can be found at 
http://sourceforge.net/projects/ddrutility/

For the NTFS filesystem, it can create domain files for the MFT (file 
system table), and also the Bitmap (the used area of the disk). Someone 
recently posted in the ddrutility discussion area a very creative (but 
complicated) way of using the tools to actually create a domain file to 
target specific files.

https://sourceforge.net/p/ddrutility/discussion/general/thread/e17d000c/


On 1/4/2018 7:18 AM, Gábor STEFANIK wrote:
> > -----Original Message-----
> > From: Bug-ddrescue [mailto:bug-ddrescue-
> > address@hidden On Behalf Of Peter Clifton
> > Sent: Thursday, January 4, 2018 12:02 PM
> > To: address@hidden
> > Subject: [Bug-ddrescue] Suggestion / feature request - bad head mapping
> >
> > Hi,
> >
> > I've been dumping a disk with ddrescue for a friend, and it occurred to me
> > that one feature present in hardware based / proprietary recovery tools (as
> > far as I could discern from watching youtube videos of professional
> > recovery), is bad-head mapping.
> >
> > The pattern of slow / bad reads from this particular disk appears to be 75%
> > good, 25% bad, in a fairly regular pattern. I know the disk has 2x platters, 4x
> > heads, so this suggests (possibly), a damaged region of one platter face, or
> > one read head wearing or damaged more significantly than the others.
> >
> > I was curious as to whether you had suggestion how (or interest in adding a
> > feature), to have ddrescue focus on the 3/4 of the disk which is more readily
> > accessible.
> >
> > I understand that LBA to head mapping can very quite significantly between
> > different types of drive though, and I have no idea of the techniques used by
> > the proprietary disk recovery tools to determine this mapping. (From the
> > video I saw, it seemed to be read or determined by scanning the drive
> > somehow.)
> >
> > Anyhow - also wanted to say thanks for the utility. An improvement over
> > dd_rescue, and I'm sure it has saved many people much data. In this case,
> > fortunately - the drive was _just_ accessible enough to pull the majority of
> > the user files my friend wanted through the filesystem before starting the
> > full disk image.
> >
> > I guess a related (but very advanced) feature one could imagine adding at
> > some future point, is persuading ddrescue to focus on sectors of the disk
> > which are identified as containing desired filesystem data (as proprietary
> > tools do). Obviously this would require connecting with a filesystem driver,
> > so would be rather a complex task. Is this kind of functionality on your wish-
> > list for the future, or out of scope for ddrescue development?
> >
> >
> > Kind regards,
> >
> > Peter
> Hi,
>
> Domain mapfiles can be used for both purposes. You need a separate tool to 
> generate mapfiles containing the sectors accessible through each head. Then, 
> get the sector map of the desired files using another utility (in mapfile 
> format), and finally combine the mapfiles using the ddrescuelog command.
>
> It would be probably best to automate this using some wrapper (with a GUI or 
> curses-based interface). It's definitely beyond the scope of ddrescue itself.
> ________________________________
>   This message, including its attachments, is confidential and the property of 
> NNG Llc. For more information please read NNG's email policy here:
> http://www.nng.com/emailpolicy/
> By responding to this email you accept the email policy.
>
> _______________________________________________
> Bug-ddrescue mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/bug-ddrescue