ddrescue and NTFS-3g

[Corey Flood]

Antonio,

Hi, love the awesome job on ddrescue. I had a question that I have been unable to figure out/sufficiently test. I work in PC Repair and we do quite a bit of data rescue. With that said, we have noticed random spikes in NTFS-3g processor usage when utilizing an NTFS drive as a repository for the images. We have actually been noticing this for a while, but only recently pegged it to NTFS-3g. I looked on their support page, and they mention block size and sparse writes being issues when using dd, so I assume similar issues here. We did use ext3 as a storage volume for the images, and noticed a marked improvement.

With that all said, I know there would be issues in doing data recovery with large block sizes (higher rate of missing data, etc.), but I am wondering if the asynchronous switch would be able to help with this, or perhaps a quick run through with a large block size, no trim, etc, then a second pass with a smaller one.

Just wondering what type of thoughts you have on this. Thanks for your help and keep up the great work!

-Corey Flood

_______________________________________________
Bug-ddrescue mailing list
Bug-ddrescue@...
http://lists.gnu.org/mailman/listinfo/bug-ddrescue

[Antonio Diaz Diaz-2]

Corey Flood wrote:
> With that all said, I know there would be issues in doing data recovery with
> large block sizes (higher rate of missing data, etc.), but I am wondering if
> the asynchronous switch would be able to help with this, or perhaps a quick
> run through with a large block size, no trim, etc, then a second pass with a
> smaller one.

I suppose you mean the "--synchronous" switch. This switch issues a
fsync call after every write to the output file. Not sure if this will
help with the NTFS problems.

You can't avoid the trim without manually interrupting ddrescue. What
you can try is a first pass with --no-split and a large value for
--cluster-size, say 1024, followed by a default pass with --retrim,
--try-again and perhaps --direct:

   ddrescue --no-split --cluster-size=1024 in out log
   ddrescue --retrim --try-again --direct in out log


Regards,
Antonio.


_______________________________________________
Bug-ddrescue mailing list
Bug-ddrescue@...
http://lists.gnu.org/mailman/listinfo/bug-ddrescue

[Gene Vayngrib]

I feel I need to report here a huge problem I had with ntfs-3g and the one I researched for hours.
I have seen other people report it as well but no real solution was suggested.
I had a ddrescue imaging to a file on an ntfs partition (mounted with ntfs-3g) on a USB drive on Ubuntu 9.04 LiveCD. It was going slower and slower, although number of errors was not increasing. I tried all the ddrescue options I could find, but nothing helped - it was working for 5 days already and was slowing down so much so it would never end. By the time I stopped it it copied 112Gb out of 223Gb.
Then I noticed that ntfs-3g was eating 100% cpu. So, I created an ext3 partition on the same USB drive, copied my image file and log there and restarted ddrescue.
Boy! it finished in a couple of hours!

Hope this helps. I still have the original drive, and plan to send the laptop with it for repair tomorrow evening. So if you want me to try something to see what causes the problem - let me know.

Gene

[Antonio Diaz Diaz-2]

Gene Vayngrib wrote:
> I feel I need to report here a huge problem I had with ntfs-3g and the one I
> researched for hours.

Thanks for the feedback. I am sure your findings will be useful for some
ddrescue users.


Regards,
Antonio.


_______________________________________________
Bug-ddrescue mailing list
Bug-ddrescue@...
http://lists.gnu.org/mailman/listinfo/bug-ddrescue