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

[Scott Dwyer]

After doing some quick math on a part of the logfile, I came up with a 
ratio of 5.77, which means that 6 heads is about right. And a closer 
visual assessment says the same thing.

Scott


On 2/6/2014 4:05 AM, David Deutsch wrote:
> 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