GNU ddrescue imaging results -- 116 errors a lot?

Question

A little background on this.

It's an 256 GB SSD drive with Windows SP3 32-bit and it's encrypted with PGP Whole Disk Encryption. The file system is corrupt and unreadable.

I first ran Clonezilla to clone the drive with -q1 (sector clone) and Clonezilla could not start the clone process because it said the drive is physically damaged (does it determine this by using SMART or looking at the G-List?). I then checked off -rescue (skips bad sectors) and it cloned.

I wanted a better image/clone so I found Ubuntu Rescue Remix Live CD and ran GNU ddrescue. I created an image of the SSD drive using the following syntax: sudo ddrescue -r 5 -v -d {source drive} {dest drive/imgfile} logfile (retries bad sectors 5 times; verbose output to screen; direct access mode to skip kernel cache).

It finished in 2:30-3:00 hours. The average transfer rate was around (25.88 MB/s) (I used eSATA and SATA, respectively, to transfer data). It also lists "errors: 116" and "errsize: 470 kB". For the record, the program lists "Sector size: 512 bytes" and "Copy block size: 128 sectors".

(I cannot post an image because I am new.)

Two things:

1. Are the results saying that 116 errors (sectors or blocks?) totaling 470 kB were found and transferred or found and not transferred? If you notice, the program says it's about to copy 256052 MB and it says it rescued 256052 MB. So, I'm really not sure.
2. Is 116 errors considered to be a lot and indicative of physical damage?

For the moment, I can confirm that, at the very least, over 99% of data was transferred. I'd say that's pretty good. In fact, the rough calculation is: 1 - (470 kB/256 GB) =~ 0.9999981640625 --> 0.9999981640625 * 100 ~ 99.9998%.

Again, Clonezilla couldn't clone, at first, because it reported that the drive is physically damaged. Yet, while GNU ddrescue reported 116 errors, at least most of the data was imaged. I know there are logical errors on the drive. But is this drive physically damaged based on 116 errors totaling 470 kB?

Lastly, what is an error? Is that number of bad blocks, sectors, or something else? And is it at all related to errsize. In my case, it's 116 errors and errsize of 470 kB. But I have seen other scans on the Internet with 1 error and 500 GB errsize. So, I'm not sure what the correlation is there.

Update

I got no reply so I'll update and hope someone out there smarter than me will reply with some answers.

I ran GNU ddrescue once more, with read retries increased from 5 to 20. Everything else is the same, including the results (it took slightly longer to image than the first time, because of the read retry increase). Yes, the error count and error size (still don't understand their relationship or what an error means in this program) are 116 and 470 kB, exactly the same as the first time I imaged with this program. What could that mean? Put a gun to my head, I'd say this SSD drive is not physically damaged. And if it is, it's slight. I still don't know if 116 errors is a lot, but here's why I think there's no physical damage. If there was, wouldn't the error count and error size go UP the 2nd time I imaged the drive, especially with increasing the read retries to 20?

I wanted the errors to go down, which is why I tried imaging again. I don't have much experience with SSDs. But perhaps they differ from mechanical disks in that if you can't read a bad block, most likely you won't be able to, no matter how many times you retry. I'm assuming data recovery services have vastly superior software and hardware tools that could read bad blocks from an SSD, however.

This SSD drive has been slaved quite a few times to analyze and also attempt decryption. I've cloned with it Clonezilla (which claims it's physically damaged), and then I imaged it twice with GNU ddrescue with one parameter value increased and the image results are exactly the same. One would think that with all that this drive has been through, if it was failing, it would take a long time to read from/write to and the number of errors would increase. But none of that has happened. Maybe I'm just getting lucky and it is physically damaged. But if it is, I think it's slight.

But I'll ask again: Is 116 errors a lot? What's the correlation of errors to error size, when I've read accounts of image results with 1 error and an error size of many, many GBs? And is an error here in terms of sectors, blocks, or some other measurement?

Thank you.

Answer 1

The ddrescue manual's Algorithm section describes errsize and errors. errsize is the sum of the sizes of the bad-sector "blocks" where a "block" is ddrescue's term for a range of contiguous bad sectors. On the other hand, errors is the count of these bad-sector "blocks".

As the manual describes, on each pass after the first, the bad-sector "blocks" are retried and might get split up. As bad sectors are read successfully, errsize will decrease and errors could increase or decrease (because a block might get split by a good sector or all the bad sectors in a block have been successfully read, respectively).

So, answering your question, "is the number errors is a lot?", you have to look at the errsize rather than errors. On a 256GB SSD, I don't think 470kB (less than 0.0002% of the drive) are very many errors at all.

You should also look at smartctl and the S.M.A.R.T. self-tests to sense of the health of the drive. IMHO, once a drive starts failing the pre-fail tests, it's usually not worth the risk of data loss to continue using the drive.