Is my Harddrive failing?

[Alan Cox]

>  Oct 31 08:05:04 merk kernel:         res
> 41/40:00:af:3a:d7/30:00:1e:00:00/00 Emask 0x409 (media error) <F>
>  Oct 31 08:05:04 merk kernel: ata1.00: status: { DRDY ERR }
>  Oct 31 08:05:04 merk kernel: ata1.00: error: { UNC } 
That is the drive reporting a bad block yes. Whether it is a one off
failure or the start of a pattern of fails ending in doom is
unfortunately rather harder to tell.

Alan

[Matthew Saltzman]

On Sat, 2009-10-31 at 11:39 +0000, Alan Cox wrote: 
>  > Oct 31 08:05:04 merk kernel:         res
> 41/40:00:af:3a:d7/30:00:1e:00:00/00 Emask 0x409 (media error) <F>
>  > Oct 31 08:05:04 merk kernel: ata1.00: status: { DRDY ERR }
>  > Oct 31 08:05:04 merk kernel: ata1.00: error: { UNC }
>  
>  That is the drive reporting a bad block yes. Whether it is a one off
>  failure or the start of a pattern of fails ending in doom is
>  unfortunately rather harder to tell. 
It used to be fairly common for new disks to have a few bad blocks--back
in the dark days of early PCs when disk drive capacities were measured
in tens or low hundreds of megabytes.  Then things seemed to improve as
manufacturing techniques improved.  When disk capacities were measured
in tens or low hundreds of gigabytes, I don't recall ever encountering a
new drive with bad blocks.  Now that capacities have reached the
terabyte range, it seems that a few bad blocks on new drives are once
again less rare.

It would be nice if the monitor software could record the state of a
drive and issue reports when the number of bad blocks increases from the
starting state, rather than insisting that every bad block is a sign of
imminent failure.  The persistent false alarm provokes the user to
ignore the monitor or turn it off entirely, thus risking missing a
warning of an imminent real failure.

>  
>  Alan
>  
>   
-- 
                Matthew Saltzman

Clemson University Math Sciences
mjs AT clemson DOT edu
http://www.math.clemson.edu/~mjs

[SternData]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/30/2009 11:27 PM, Frederick Abrams wrote:
>  Hiya,
>  
>  Laptop Specs Attached (lshw)
>  
>  My PC was running perfect not a single error and then after i rebooted
>  the PC was working extemely slowly i checked /var/log/messages and i get
>  the below output.
>   
  // snip //

>   
It might be a good idea to see what the SMART diagnostics can do

As root, in a very wide terminal window

   smartctl -a /dev/sda

will get you a status report on the disk. Look at the rightmost columns
for the actual reported values.

Then, run a long selftest

   smartctl -t long /dev/sda

Finally, check the results some time after smartctl's estimated time to
run the test

   smartctl -l selftest /dev/sda

For more, see 'man smartctl'



- -- 

  Steve
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAkrsaXgACgkQeERILVgMyvDXyQCfVgV9cRUSHnrxPF0nHyE96Cbr
> gfcAn2Dq+p7JP4h82gxil/zO/T659uN8
> =QAJr
> -----END PGP SIGNATURE-----

[Jonathan Ryshpan]

On Sat, 2009-10-31 at 12:24 -0400, Matthew Saltzman wrote:
>  On Sat, 2009-10-31 at 11:39 +0000, Alan Cox wrote: 
>  > > Oct 31 08:05:04 merk kernel:         res 41/40:00:af:3a:d7/30:00:1e:00:00/00
> Emask 0x409 (media error) <F>
>  > > Oct 31 08:05:04 merk kernel: ata1.00: status: { DRDY ERR }
>  > > Oct 31 08:05:04 merk kernel: ata1.00: error: { UNC }
>  > 
>  > That is the drive reporting a bad block yes. Whether it is a one off
>  > failure or the start of a pattern of fails ending in doom is
>  > unfortunately rather harder to tell.
>  
>  It used to be fairly common for new disks to have a few bad blocks--back
>  in the dark days of early PCs when disk drive capacities were measured
>  in tens or low hundreds of megabytes.  Then things seemed to improve as
>  manufacturing techniques improved.  When disk capacities were measured
>  in tens or low hundreds of gigabytes, I don't recall ever encountering a
>  new drive with bad blocks.  Now that capacities have reached the
>  terabyte range, it seems that a few bad blocks on new drives are once
>  again less rare.
>  
>  It would be nice if the monitor software could record the state of a
>  drive and issue reports when the number of bad blocks increases from the
>  starting state, rather than insisting that every bad block is a sign of
>  imminent failure.  The persistent false alarm provokes the user to
>  ignore the monitor or turn it off entirely, thus risking missing a
>  warning of an imminent real failure. 
I have a 1 Tbyte drive which has been reporting exactly 1 bad sector for
at least the last 6 months.  It always shows up on the gnome panel as
the drive troubles applet (no name -- it doesn't identify itself), and
every few days I check it.  Always exactly 1 bad sector.

I ought to fix it so as to report only increases in the number of bad
sectors, but I probably never will.

jon

[Robert Nichols]

Jonathan Ryshpan wrote:
>  I have a 1 Tbyte drive which has been reporting exactly 1 bad sector
> for
>  at least the last 6 months.  It always shows up on the gnome panel as
>  the drive troubles applet (no name -- it doesn't identify itself), and
>  every few days I check it.  Always exactly 1 bad sector.
>  
>  I ought to fix it so as to report only increases in the number of bad
>  sectors, but I probably never will. 
If you could find that bad sector and rewrite it, then the drive would
remap it to a spare sector and you wouldn't be bothered by it any more.
Tracking those down can be just _tons_ of fun, and sometimes you learn
more about filesystem structure than you ever wanted to know.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.

[Bill Case]

Hi;
On Sat, 2009-10-31 at 12:24 -0400, Matthew Saltzman wrote:
>  On Sat, 2009-10-31 at 11:39 +0000, Alan Cox wrote: 
>  > > Oct 31 08:05:04 merk kernel:         res 41/40:00:af:3a:d7/30:00:1e:00:00/00
> Emask 0x409 (media error) <F>
>  > > Oct 31 08:05:04 merk kernel: ata1.00: status: { DRDY ERR }
>  > > Oct 31 08:05:04 merk kernel: ata1.00: error: { UNC }
>  > 
>  > That is the drive reporting a bad block yes. Whether it is a one off
>  > failure or the start of a pattern of fails ending in doom is
>  > unfortunately rather harder to tell.
>  
>  It used to be fairly common for new disks to have a few bad blocks--back
>  in the dark days of early PCs when disk drive capacities were measured
>  in tens or low hundreds of megabytes.  Then things seemed to improve as
>  manufacturing techniques improved.  When disk capacities were measured
>  in tens or low hundreds of gigabytes, I don't recall ever encountering a
>  new drive with bad blocks.  Now that capacities have reached the
>  terabyte range, it seems that a few bad blocks on new drives are once
>  again less rare.
>  
>  It would be nice if the monitor software could record the state of a
>  drive and issue reports when the number of bad blocks increases from the
>  starting state, rather than insisting that every bad block is a sign of
>  imminent failure.  The persistent false alarm provokes the user to
>  ignore the monitor or turn it off entirely, thus risking missing a
>  warning of an imminent real failure. 
I have had the same complaint ever since Fedora started using the
gdu-notification-daemon at startup. I have filed the following bug
against it:

https://bugzilla.redhat.com/show_bug.cgi?id=526742


-- 
Regards Bill
Fedora 11, Gnome 2.26.3
Evo.2.26.3, Emacs 23.1.1

[Tony Nelson]

On 09-10-31 12:24:00, Matthew Saltzman wrote:
 ...
>  It used to be fairly common for new disks to have a few bad
>  blocks--back in the dark days of early PCs when disk drive capacities 
>  were measured in tens or low hundreds of megabytes.  Then things 
>  seemed to improve as manufacturing techniques improved.  When disk 
>  capacities were measured in tens or low hundreds of gigabytes, I 
>  don't recall ever encountering a new drive with bad blocks.  Now that 
>  capacities have reached the terabyte range, it seems that a few bad 
>  blocks on new drives are once again less rare. 
"Modern" drives from the last decade or more use formatting that 
skips over bad blocks.  There should /never/ be a bad block on a new 
drive.  As blocks will go bad from time to time in otherwise properly 
functioning drives, all "modern" drives have automatic recovery and 
remapping of bad blocks (but only for blocks where the data could be 
recovered or the block was written to).  (That IBM drive fiasco was 
mostly that their recovery process was very noisy and dreadfully slow.)


>  It would be nice if the monitor software could record the state of a
>  drive and issue reports when the number of bad blocks increases from
>  the starting state, rather than insisting that every bad block is a 
>  sign of imminent failure.  The persistent false alarm provokes the 
>  user to ignore the monitor or turn it off entirely, thus risking 
>  missing a warning of an imminent real failure. 
Right.  SMART already watches that bad blocks don't increase too much.  
I just let smartd mail me when it thinks the drive is going bad.  Also, 
I turn on Automatic Offline Testing, which scans the disk every few 
hours and may be able to catch a block going bad while it is still 
automatically recoverable and remap it without causing any trouble.

-- 
____________________________________________________________________
TonyN.:'                       <mailto:[e-mail]>
      '                              <http://www.georgeanelson.com/>