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

[Peter Clifton]

> 
>         > > 
> >     > 

> 
>         > > 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.
> 

Thanks for the reply. As the recovery progressed it became apparent that the 
LBA to physical mapping is quite complex. I suspect the proprietary recovery 
tools use manufacturer specific (and undocumented) ata commands / serial port 
debug to extract this information from the drive).

Do you happen to know of any recipes to extract filesystem block usage in 
mapfile format? I couldn't find anything existing, but don't want to re-invent 
a new utility.

My thinking so far...

ntfsclone allows a meta-data only clone of an NTFS volume into a sparse file. 
Assuming it can read the meta-data blocks, this sparse file should match the 
layout of the metadata blocks - although I'm not certain whether this includes 
any indirect blocks (zfs terminology?) or bitmaps locating all the user file 
data. (I'm no expert on the NTFS layout).

The next step might be to write a utility which implements a data-source for 
ntfsclone which overlays the sparse image of metadata (so the clone utility 
"sees" the filesystem), whilst constructing an extent map of all reads made 
whilst making a full clone. This extent map could then be used to feed ddrescue.

Peter