Re: [Bug-ddrescue] Feature Suggestion: Automatic Cooldown mode

[David Deutsch]

Hi Scott,

Thanks for the details. The Model number of the disk is WDC
WD20EARS-00MVWB0. The reason I assumed it would be 4 platters with 8
heads is that it's more than two years old and at the time was the
largest capacity you could get. A web search for head count is
somewhat inconclusive, with some sources claiming that the same model
might have different configurations. This here seems quite thorough
and would suggest it's actually three platters with 6 heads:

http://rml527.blogspot.de/2010/10/hdd-platter-database-western-digital-35_1109.html

I'm still having a hard time visualizing the topography of the drive
to begin with, but it does make a little more sense with your
explanation. I would agree that the most probably case, judging from
how regular the pattern is, would be that we have one side of one
platter side (=one head) producing errors with one end of the platter
being worse than the other. One head would be 333GB and since I have
already "rescued" more than 1760GB it doesn't feel like I'm that badly
off. The errsize jumped to 7.9GB during the first 128GB but hasn't
moved much since - the operation is at 748GB ipos and errsize is now
at 8.1GB. If I can continue to get the same rescue to errsize ratio
that I currently get out of it for the rest of the rescue, this would
suggest that I might end up at 10GB lost to error.

Of course - I only see this process right now, I have no experience
with fsck'ing rescued images and whether those errors end up wrecking
everything.

What I did notice is that readout seems to be slowing down again - it
was at over 100kb/s for two days but this has gone down yesterday:

GNU ddrescue 1.18-pre7
Initial status (read from logfile)
rescued:     1757 GB,  errsize:   8071 MB,  errors:   77429
Current status
rescued:     1764 GB,  errsize:   8111 MB,  current rate:        0 B/s
   ipos:   713673 MB,   errors:   87250,    average rate:    83757 B/s
   opos:   713673 MB, run time:   23.65 h,  successful read:   11.03 m ago

GNU ddrescue 1.18-pre7
rescued:     1764 GB,  errsize:   8111 MB,  errors:   87250
Current status
rescued:     1766 GB,  errsize:   8123 MB,  current rate:        0 B/s
   ipos:   745794 MB,   errors:   90348,    average rate:    62385 B/s
   opos:   745794 MB, run time:    7.70 h,  successful read:    2.11 m ago

...and it seems a lot more common that successful reads are more than
10 minutes apart. So that really does start to seem rather
excessive...

As for reading it backwards: Can I even do that at this stage in the process?

-David

On Thu, Feb 6, 2014 at 2:39 AM, Scott Dwyer <address@hidden> wrote:
> Hi David,
>
> I have looked at your logfile, and you may be in for a rougher recovery than
> I was expecting. I also had a sort of awakening about the appearance of the
> spiral pattern in ddrescueview.
>
> After absorbing information from the earlier reply from Franc Zabkar about
> how the disk will read sections of tracks from one surface (head) before
> moving on to the next, I believe that I was totally wrong about the visual
> pattern. I now believe that all the red problem area is actually all from
> one head. In your case just by the visual reference, it would appear that
> there are 4 heads (2 platters). This is assumed by the visual ratio of good
> to bad (3 good to 1 bad). The other logs I have seen like this were more
> 50/50 (2 heads / single platter). The reason it looks sort of spiral is
> because of the density difference of information per track from the outside
> to the inside of the disk (outside is bigger and holds more information per
> track). The first track is on the outside, and the last track is on the
> inside.
>
> There seems to be one thing in common from the logfiles I have seen. The
> data towards the inside of the disk seems to be less prone to errors (easier
> to read because the data is going past the head slower?) Unfortunately from
> what I can see from your logfile, the data towards the outside is really bad
> with no noticeable recovered data. It doesn't start to show any promise
> until it gets farther in. Sorry for that news after possibly getting your
> hopes up. Guess I should learn to see the logfile before making predictions.
>
> And you are correct that ddrutility will not help you. The only part of it
> that works with linux ext3 filesystems is the findbad bash script to find
> what files are affected. It won't work on damaged filesystems, and even if
> it did, it could take days or weeks (or longer) to complete on a recovery
> that has a large error size like you are likely to end up with.
>
> I just had a thought. Based on the pattern that I have seen, I wonder if it
> would be more productive to read backwards from the end, since it seems to
> be more likely to produce recovered data quicker. Something to think
> about...
>
>
> Scott
>
>
> On 2/4/2014 7:47 PM, David Deutsch wrote:
>>
>> Hi Scott,
>>
>> Wow, no, I did not see that at all! Sorry for seemingly ignoring you
>> for days, now. Not sure whether it's my gmail account or something...
>> Weird. Probably because I messed up my replies in the beginning.
>>
>> (replying to the points raised in that email since they also answer
>> your current questions)
>>
>>> Both finished logs showed something interesting, in that there were many
>>> small errors in what could almost be considered a spiral pattern
>>
>> Yeah, that's pretty much exactly the thing with my drive - it seems
>> like all bad sectors found are 512 Bytes.
>>
>>> The fun part was that the filesystem (it was an NTFS disk) was so messed
>>> up that nothing would mount it
>>
>> Maybe I got lucky there since I was using ext3.
>>
>>> even testdisk failed to find a large portion of the files. So be prepared
>>> to use something more robust than testdisk (like R-Studio) if you go through
>>> with the rest of the recovery.
>>
>> Yeah, that really is the scary part - Since we're talking about 1TB of
>> DSLR files (.JPG, .MOV) and music (flac, mp3) each, I would really
>> like to see this mounted. I have 'rescued' a number of disks for other
>> people and losing all the nice meta-data (directories etc.) would
>> be... quite a bummer. The music stuff I would probably just have to
>> redo from my CD collection... *sigh*
>>
>>> ddrutility
>>
>> >From what I understand that is mostly about your case, rescuing ntfs
>> partitions? Or would it help in my case as well?
>>
>>> Third, I am interested in a copy of your logfile if possible. Actually I
>>> would like the first one you sent to Antonio if you still have it, and also
>>> your current one.
>>
>> Sure thing. Will send them along in a separate message.
>>
>> cheers,
>> David
>>
>> On Wed, Feb 5, 2014 at 1:25 AM, Scott Dwyer <address@hidden> wrote:
>>>
>>> Hi David,
>>>
>>> First, did you see my reply with my 2 cents? It contained some info (my
>>> opinion) as to what might have happened to your drive, and what you might
>>> expect (from my experience). I only replied to the bug list, so if you
>>> did
>>> not see it then you will have to look into the archives which can be
>>> found
>>> through the ddrescue page.
>>> http://lists.gnu.org/archive/html/bug-ddrescue/
>>>
>>> Second, while errors are skipped, every error takes time to process,
>>> first
>>> by the drive itself and then that is multiplied by any op system retries
>>> (from what I can tell in linux from observation, it is about 15 retries
>>> normally, or 5 retries using the direct option). So if the drive takes 3
>>> seconds per error, then it would take 15 seconds with the direct option
>>> to
>>> process the error, or 45 seconds without the direct option. I used 3
>>> seconds
>>> for the drive as that is about an average from a few drives I have seen,
>>> but
>>> that is dependent on the drive itself. Doing a little math on that means
>>> that at 15 seconds per error, you could process about 5760 errors per
>>> day.
>>> And you are going to have a LOT of errors by the looks of it, so you are
>>> in
>>> for a long recovery. But don't be too discouraged just yet. You will have
>>> many errors spread all over, but there is still a chance that you will
>>> end
>>> up with 99% of good sectors vs bad, not to say that file recovery will be
>>> easy when done. What file system is this? Is is NTFS? What type of files
>>> will you be trying to recover?
>>>
>>> Third, I am interested in a copy of your logfile if possible. Actually I
>>> would like the first one you sent to Antonio if you still have it, and
>>> also
>>> your current one.
>>>
>>> Scott
>>>
>>>
>>>
>>> On 2/3/2014 5:00 PM, David Deutsch wrote:
>>>>
>>>> Close to breaking 1750GB, too. I think this kills the "1/8 of the disc
>>>> is dead" idea, ie. one platter/side or read head being dead. Still
>>>> curious what could produce such a regular error, though. Particularly
>>>> across the entire space of the disc. Or maybe I just have no frigging
>>>> clue how hard discs werk (I really don't).
>>>>
>>>> Reading still progresses in a steady pace in general, although it's
>>>> kind of weird: It only reads every two to three minutes, sometimes up
>>>> to ten. Not sure whether that is the drive hardware failing more, in
>>>> general (though speeds improving would say otherwise) or just the
>>>> general issue with bad sectors. Then again: Shouldn't it just skip
>>>> past those? Or are the sectors around the bad ones just hard to get
>>>> anything out of?
>>>
>>>
>> _______________________________________________
>> Bug-ddrescue mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/bug-ddrescue
>>
>