doccpu wrote: 10 Sep 2021, 02:31
What is testdisk doing during parttion seeks or data recovery?
It's watching you via your built-in camera and sending the images to me - just kidding!
Its frustrating to see no activity and it can take an hour after i tell it to stop. My machine takes over 20 minutes to show any response and reads of a disk take hours. File recovery takes hours. Its frustrating there is no evidence the machine it running. No cpu usage in top or mem used. What is it actually doing or waiting on? whether its recovering files or searching for data it takes hours even for small reads. Is it faster from an image? can it find files in a chunk of a drive that is bigger than a partition? Will it be faster?
For me it's frustrating that people in the forum do not have the imagination to guess what information would be useful to post.
If I say "It takes so long to drive home, over 20 minutes!" the statement is useless without mentioning the track length.
And with today's widespread use of NAS (network attached storage) computers containing lots of big drives that are maybe combined in an array I don't know if you talking about a 120GB system drive that I had to rescue yesterday or maybe four 10 TB drives in NAS, working as one big virtual drive. The latter is 300 times bigger than my system drive and even though I am constantly monitoring Ebay no crystal ball has been offered yet which would give me the information you did not mention.
So, drive speed is measured in bytes/second. With a modern hard disk drives like I WD40EZRZ (4TB drive (not shingled)) I got an average transfer rate of 140 MByte/second writing test files using a notebook that I connected to a USB 3.0 docking station - the notebook has USB 3.0 sockets as well.
When dealing with Testdisk you can quote the percentage progress of the drive and the time used. Once the model is known wee can simply multiply it's size multiplied by the progress figure divided by the time consumed so far to arrive at a speed figure.
When talking about speed you should mention your drive size and possibly model, too, because that enables me to look up its native sustained speed.
But you did not even bother telling about if you ran a quick search or a deep search which makes a big speed difference.
Now, after having left me completely in the dark with regards to useful information I can only give you a generalized hint:
When dealing with a probably broken drive, check it's SMART parameters as described here:
When you have pending sectors or reallocated sectors you are better of duplicating your failing drive to a healthy one using ddrescue as described in the manual.
When dealing with the copy you know that you successfully excluded delays based on unreadable broken sectors.
I can't tell you how fast quick search is, but for a deep search the sustained transfer rate is my orientation mark. As for the WD40EZRZ I know I can get 140MByte/second in my personal setting as external drive connect to a notebook. Reading it will cost 8 hours. Even if Testdisk was to work at 35 MByte/second only I know it will be ready after 32 hours.
What I never can foresee is the duplication time of ddrescue with broken drives. The 2,5'' drive, a system drive of a notebook from a collegue had more than 12000 sector read errors. I think ddrescue ran days until I stopped it because there was no progress visible anymore.
Getting back to your question, file recovery fragmentation may slow down Testdisk as well but I suppose unreadable sectors are the number one reason for a slowdown.