Laptop Saved! (was RAM Mapping Script)

Ben Scott dragonhawk at gmail.com
Thu Mar 6 18:11:11 EST 2008


[aggregate reply to multiple people]

On Wed, Mar 5, 2008 at 4:28 PM, Jim Kuzdrall <gnhlug at intrel.com> wrote:
>     So it appeared to be a hangup in the drive's internal controller
>  when it has a long series of read/writes to do.

  It could also be that there are bad blocks/sectors on the disk
itself.  I've encountered situations where something (drive
firmware/drive electronics/host adapter/whatever) gets terminally
wedged trying to recover from bad sectors.

  Nominally, the cost effective thing to do is discard the drive, but
we've been over that, so here's some more ideas that probably won't
work....  :-)

  **WARNING**: "badblocks -w" nominally DESTROYS ALL DATA ON THE DRIVE.

  Running "badblocks -w" (destructive write test) on a failing drive
will sometimes revive it, at least for a while.  There's even a
reason: If a modern drive encounters a bad sector trying to service a
read request, it will not remap that logical address to a spare sector
until it can successfully read the data.  (You might want that data,
after all.)  But when new data (the badblocks test pattern) gets
written to that same logical address, the drive knows it can remap to
a spare sector and discard whatever was in the bad sector.  (The
badblocks "non-destructive write test" first reads the contents of
every block (so it can preserve and re-write the contents), so that
won't work for this.)

  IBM/Hitachi/whoever-they-are-now provides utilities that attempt to
diagnose problems on a drive.  They also provide firmware updates for
many of their drives.  Check their website for these and see if they
have anything for your drive.

  There may be a way to send a "reformat" command to the drive using
available utilities (either OEM, or third-party).  Nominally, modern
drives are low-level formatted for life by the factory, but sometimes
there are still things that can be "reformatted" in the field, and
that might revive a failing drive.  Sometimes third-parties have
figured out OEM-specific commands that do this.  Not sure where you'd
begin looking, though.

On Wed, Mar 5, 2008 at 4:28 PM, Jim Kuzdrall <gnhlug at intrel.com> wrote:
> Ice cream to sooth nerves (6 times)        33.37

  Ah-hah!  A smart man knows that the proper tools can make a huge
difference.  I knew I was missing some critical tools from my bench at
work.  I will have to put in a requisition for that!  :-D

On Wed, Mar 5, 2008 at 9:38 PM, Bill McGonigle <bill at bfccomputing.com> wrote:
> Usually when a drive fails -c, there's also a S.M.A.R.T.  error code.

  I haven't been keeping statistics, but I know I've had more than two
drives that were far enough gone that they were causing problems in
the OS, but that SMART said were still hunky-doory.

On Thu, Mar 6, 2008 at 10:47 AM, Tom Buskey <tom at buskey.name> wrote:
> I usually use DBAN or Knoppix and scrub, but if they drive doesn't spin I'd
> like more.

  At work, experimentation found that sandblasting was "best" (for our
definition of "best").  But then, we already had the sandblasting
station.  A bench grinder also ate through the platter fairly easily
(not quite like a knife through butter, but close), but there was
always a piece left over where we had to grip the platter with pliers.

  Anything that didn't completely obliterate the recording surface --
e.g., drilling holes, hitting it with a hammer, data overwrite --
wasn't acceptable.  I believe chemicals were acceptable, but only if
they dissolved a certain measurable thickness from the platters, and
anything that strong has high purchase/handling/disposal costs, and we
didn't already have some.  Magnets were easiest of all, but approved
degaussing magnets started at around $1000.

  For regular business data of normal sensitivity, I use DBAN if the
drive works, or repeated applications of a drill press if it doesn't.

-- Ben


More information about the gnhlug-discuss mailing list