trial and error attempt to use ddrutil

[Anonymous]

attempting to recover a failing NTFS partition. have been successfully using ddrescue, but wanted to use ddru_ntfsbitmap to limit the rest of the rescue to the important areas. here's an fdisk for teh current setup:

---

Disk /dev/sda: 320.1 GB, 320072933376 bytes
255 heads, 63 sectors/track, 38913 cylinders, total 625142448 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0009930f

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 625141759 312569856 83 Linux

Disk /dev/sdd: 250.1 GB, 250059350016 bytes
255 heads, 63 sectors/track, 30401 cylinders, total 488397168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xd6388451

Device Boot Start End Blocks Id System
/dev/sdd1 2048 3074047 1536000 27 Hidden NTFS WinRE
/dev/sdd2 * 3074048 470738943 233832448 7 HPFS/NTFS/exFAT
/dev/sdd3 470738944 488396799 8828928 17 Hidden HPFS/NTFS

---

sdd has the standard Dell windows partition setup. I've been ddrescuing /dev/sdd2 using variations of the following command:

ddrescue --verbose -n -d /dev/sdd2 /media/sda1/images/diskimage.img /media/sda1/images/Recovery.log

so, to create a ddru log file and use the -m option going forward, i ran:
ddru_ntfsbitmap /dev/sdd2 /media/sda1/ddru2/ddru_log.log -V

the following text flew by:

---

ddru_ntfsbitmap 1.0 20131209

Reading boot sector...
command = ddrescue -i0 -o0 -s512 /dev/sdd2 '__bootsec' '__bootsec.log'

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued: 512 B, errsize: 0 B, current rate: 512 B/s
ipos: 0 B, errors: 0, average rate: 512 B/s
opos: 0 B, time since last successful read: 0 s
Finished

Reading bitmap inode from mft...
command = ddrescue -i3221225472 -o0 -s16384 /dev/sdd2 '__mftshort' '__mftshort.log'

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued: 16384 B, errsize: 0 B, current rate: 16384 B/s
ipos: 3221 MB, errors: 0, average rate: 16384 B/s
opos: 0 B, time since last successful read: 0 s
Finished

............Reading part 0 of $Bitmap...........
command = ddrescue -i6242304 -o0 -s7307264 /dev/sdd2 '__bitmapfile' '_part0__bitmapfile.log'

GNU ddrescue 1.16
Press Ctrl-C to interrupt
rescued: 7307 kB, errsize: 0 B, current rate: 7307 kB/s
ipos: 13500 kB, errors: 0, average rate: 7307 kB/s
opos: 7258 kB, time since last successful read: 0 s
Finished

............ Done reading part 0 of $Bitmap...........
Creating ddrescue logfile...
end = 239444426752
total_size = 239444426752
Finished creating logfile
total= 239444426752 bytes
used= 38554464256 (16.10%)
free= 200889962496 (83.90%)
ddru_ntfsbitmap took 2.371840 seconds to complete

---

the usage details at the end match the df output pretty well:

Filesystem     1K-blocks      Used Available Use% Mounted on
/dev/sdd2      233832444  37650840 196181604  17% /media/sdd2

so now I have a ddru_log.log file. file consolidation seems very sparse, the ddresciewview image of the file usage is attached.

[Anonymous]

image attached

[Nick J.]

i've attached a gzipped copy of the logfile that goes with the graphic above. notice that there are a lot of empty sections. this is likely the 'slack space' between files, assuming the filesystem will place a file at the start of an empty cluster, leaving a gap at the end of other files.

some very limited and inconclusive trial and error copying using this logfile with the ddrescue -m option "seems" to indicate that these gaps are slowing down the copy. so far I've only been able to go over 20kB/sec in areas with large files. areas with any small gaps don't do well during the 'copy untried areas' phase, but then ddrescue picks them all up (very slowly) during the trimming / retrying phase. I seem to recall the tool using cluster/sector copies for different modes. so this could be specific to my drive, as it will often get stuck on errors when 'copying untried' until the drive goes nonresponsive, but in splitting/trimming/retrying it'll go for hours moving through the same high error count sections (often rescueing everything by the time its done)

[Nick J.]

and... I posted those without logging in. its been one of those days :)

[Nick J.]

another comment on using the resulting logfile:

not sure how ddrescue operates with the -m option, but my current logfile is has about 6500 entries (before knowing where the data was, I'd been jumping around the drive pulling in different sections since it drops out a lot).

when using the -m ddrulog option, it takes over a minute to begin the copying operation, and the cpu spikes as well. Then during the run, my recover.log file jumps to about 60000 entries and the cpu level stays very high. after the run it goes back down to the ~6500 level. my guess is that ddrescue pre-processes the recovery log file and sets aside sections that match he -m file. (e.g, there were adjacent sections marked 'non-tried'). i attached the logs as them as "during" and "after".

this was a minor annoyance for me as I'm doing frequent stops/restarts with the drive dropping out frequently. I did find that if I restrict the run to a certain section (something like -s2GB), then the delay and increase in size is negligible.

[Nick J.]

and regarding rescue speeds: I was doing a (very slow) area using the ddrulogfile. when the drive cutout, I reran a the area without the logfile. it was rescuing at about the same rate. so I don't think the discontinuous ddrulog file made too much of a difference. likely it's just going to be a slow stubborn rescue

[maximus57]

I have just released ddrutility 2.2, in which ddru_ntfsbitmap now has an option to bridge the small gaps. Whether or not this option is beneficial is yet to be seen. It can make the domain logfile smaller, but I am doubtful that it will help much with actual read speeds.