Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #159315 > unrolled thread

impending disk failure?

Back to article view | Back to linux.debian.user

Contents

  impending disk failure? Tony van der Hoff <tony@vanderhoff.org> - 2015-10-17 15:20 +0200
    Re: impending disk failure? <tomas@tuxteam.de> - 2015-10-17 17:00 +0200
    Re: impending disk failure? Miles Fidelman <mfidelman@meetinghouse.net> - 2015-10-17 18:50 +0200
      Re: impending disk failure? Dominique Dumont <dod@debian.org> - 2015-10-18 10:40 +0200
        Re: impending disk failure? Himanshu Shekhar <irm2015006@iiita.ac.in> - 2015-10-18 10:50 +0200
      Re: impending disk failure? Tony van der Hoff <tony@vanderhoff.org> - 2015-10-20 12:10 +0200
        Re: impending disk failure? Ondřej Grover <ondrej.grover@gmail.com> - 2015-10-20 12:30 +0200
          Re: impending disk failure? Tony van der Hoff <tony@vanderhoff.org> - 2015-10-20 12:40 +0200
        Re: impending disk failure? Miles Fidelman <mfidelman@meetinghouse.net> - 2015-10-20 15:50 +0200
    Re: impending disk failure? Dominique Dumont <dod@debian.org> - 2015-10-17 18:50 +0200
    Re: impending disk failure? Mirko Parthey <mirko.parthey@web.de> - 2015-10-20 14:30 +0200

#159315 — impending disk failure?

Hi,

T'm occasionally getting this message in syslog on my jessie box:

Oct 17 12:00:19 tony-lx kernel: [ 8838.600489] ata3.00: exception Emask 
0x10 SAct 0x10 SErr 0x400000 action 0x6 frozen
Oct 17 12:00:19 tony-lx kernel: [ 8838.600501] ata3.00: irq_stat 
0x08000000, interface fatal error
Oct 17 12:00:19 tony-lx kernel: [ 8838.600509] ata3: SError: { Handshk }
Oct 17 12:00:19 tony-lx kernel: [ 8838.600517] ata3.00: failed command: 
WRITE FPDMA QUEUED
Oct 17 12:00:19 tony-lx kernel: [ 8838.600531] ata3.00: cmd 
61/c0:20:90:6e:eb/01:00:22:00:00/40 tag 4 ncq 229376 out
Oct 17 12:00:19 tony-lx kernel: [ 8838.600531]          res 
40/00:20:90:6e:eb/00:00:22:00:00/40 Emask 0x10 (ATA bus error)
Oct 17 12:00:19 tony-lx kernel: [ 8838.600538] ata3.00: status: { DRDY }
Oct 17 12:00:19 tony-lx kernel: [ 8838.600547] ata3: hard resetting link
Oct 17 12:00:20 tony-lx kernel: [ 8839.092521] ata3: SATA link up 6.0 
Gbps (SStatus 133 SControl 300)
Oct 17 12:00:20 tony-lx kernel: [ 8839.099092] ata3.00: configured for 
UDMA/133
Oct 17 12:00:20 tony-lx kernel: [ 8839.099121] ata3: EH complete


Can anyone please explain what it means, and whether I should be worried?

Thanks,
-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [next] | [standalone]

#159321

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

On Sat, Oct 17, 2015 at 02:15:52PM +0100, Tony van der Hoff wrote:
> Hi,
> 
> T'm occasionally getting this message in syslog on my jessie box:
> 
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600489] ata3.00: exception
> Emask 0x10 SAct 0x10 SErr 0x400000 action 0x6 frozen
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600501] ata3.00: irq_stat
> 0x08000000, interface fatal error
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600509] ata3: SError: { Handshk }
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600517] ata3.00: failed
> command: WRITE FPDMA QUEUED
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600531] ata3.00: cmd
> 61/c0:20:90:6e:eb/01:00:22:00:00/40 tag 4 ncq 229376 out
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600531]          res
> 40/00:20:90:6e:eb/00:00:22:00:00/40 Emask 0x10 (ATA bus error)
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600538] ata3.00: status: { DRDY }
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600547] ata3: hard resetting link
> Oct 17 12:00:20 tony-lx kernel: [ 8839.092521] ata3: SATA link up
> 6.0 Gbps (SStatus 133 SControl 300)
> Oct 17 12:00:20 tony-lx kernel: [ 8839.099092] ata3.00: configured
> for UDMA/133
> Oct 17 12:00:20 tony-lx kernel: [ 8839.099121] ata3: EH complete

Hmpf. Could be anything. But as a first shot I'd try unseating and
re-seating the disk's SATA cable (or exchanging it). And before and
above everything: make frequent backups!

regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlYiV+MACgkQBcgs9XrR2kZ5pwCfdopAWMpZYyEUzxD0Bq6gYMmi
SdQAnRfbuxXBXZl+r+pExmSEzb4bykeZ
=jdUX
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#159325

Dominique Dumont wrote:
> On Saturday 17 October 2015 14:15:52 Tony van der Hoff wrote:
>> Can anyone please explain what it means, and whether I should be worried?
> You should check the drive with smartctl.
>
> See http://www.smartmontools.org/
>
> HTH
>
Yes.. and be sure to go beyond the basic tests.

First off, make sure it's running:
smartctl -s on -A /dev/disk0   ;for each drive, and using the 
appropriate /dev/..

Then after, it's accumulated some stats:
smartctl -A /dev/disk0

For a lot of drives, the first line - raw read errors, can be very telling - anything other than 0, and your disk is failing.
Start-up-time can be telling, if it's increasing.

The thing is, that most drives, except those designed for use in RAID arrays, mask impending disk failures, by re-reading blocks multiple
times - they often get the data eventually, but your machine keeps getting slower and slower.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

[toc] | [prev] | [next] | [standalone]

#159370

On Saturday 17 October 2015 12:47:36 Miles Fidelman wrote:
> For a lot of drives, the first line - raw read errors, can be very telling -
> anything other than 0, and your disk is failing.

Sorry, the FAQ [1] on smartmontools.org does not agree with your statement:

* What details can be interpreted from Raw read error rate?
  If no documentation is available, the RAW value of attribute 1 is typically useless. 
 The 48-bit field might encode several values, try -v 1,hex48 to check. 

All the best

[1] http://www.smartmontools.org/wiki/FAQ#WhatdetailscanbeinterpretedfromRawreaderrorrate
-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

[toc] | [prev] | [next] | [standalone]

#159372

[Multipart message — attachments visible in raw view] — view raw

Hi!
You can use Disk Utility (gnome-disks / udisks) and check your hard drive
for errors, or bad sectors.
That seems to be simple enough!

Regards
Himanshu Shekhar
IIIT-Allahabad
IRM2015006

[toc] | [prev] | [next] | [standalone]

#159521

On 17/10/15 17:47, Miles Fidelman wrote:
> Dominique Dumont wrote:
>> On Saturday 17 October 2015 14:15:52 Tony van der Hoff wrote:
>>> Can anyone please explain what it means, and whether I should be
>>> worried?
>> You should check the drive with smartctl.
>>
>> See http://www.smartmontools.org/
>>
>> HTH
>>
> Yes.. and be sure to go beyond the basic tests.
>
> First off, make sure it's running:
> smartctl -s on -A /dev/disk0   ;for each drive, and using the
> appropriate /dev/..
>
> Then after, it's accumulated some stats:
> smartctl -A /dev/disk0
>
> For a lot of drives, the first line - raw read errors, can be very
> telling - anything other than 0, and your disk is failing.
> Start-up-time can be telling, if it's increasing.
>
> The thing is, that most drives, except those designed for use in RAID
> arrays, mask impending disk failures, by re-reading blocks multiple
> times - they often get the data eventually, but your machine keeps
> getting slower and slower.
>


Thanks Miles, and tomás, for your helpful replies.

I apologise for the delay in replying, but I've been away from my desk a 
few days.

I have however been doing some extensive googling, and it would appear 
that the raw read error count is something of a red herring, especially 
when applied to Seagate drives, as these are. Both my drives have quite 
high (in the millions) of RREC; numbers which are precisely matched by 
the Hardware ECC Recovered counts, suggesting that the RREC is merely an 
artifact od HHDs being essentially a mechanical device, being pushed to 
its limits using clever technology. The SMART extended tests reveal no 
problems.

The Wikipedia entry https://en.wikipedia.org/wiki/S.M.A.R.T. is 
particularly informative in the relative importance of these error 
counts; the RREC can be safely ignored, as somebody else here recently 
suggested.

So, back to the original problem; I think tomás hit the nail on the 
head. I've re-plugged the SATA cables, to no great effect; I have now 
ordered a couple of new cables, and will see whether that helps.

Thanks again to  all.



-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [prev] | [next] | [standalone]

#159523

[Multipart message — attachments visible in raw view] — view raw

Does this error occur by any chance after resuming from suspended state? I
had a similar problem because of some faulty drivers, setting
echo 0 > /sys/power/pm_async
makes sure that drivers do not resume asynchronously and it might fix the
problem.
Or can it be correlated to any other system events? It might help to attach
the syslog logs with more context before and after the errors.

Kind regards,
Ondřej Grover

On Tue, Oct 20, 2015 at 12:02 PM, Tony van der Hoff <tony@vanderhoff.org>
wrote:

> On 17/10/15 17:47, Miles Fidelman wrote:
>
>> Dominique Dumont wrote:
>>
>>> On Saturday 17 October 2015 14:15:52 Tony van der Hoff wrote:
>>>
>>>> Can anyone please explain what it means, and whether I should be
>>>> worried?
>>>>
>>> You should check the drive with smartctl.
>>>
>>> See http://www.smartmontools.org/
>>>
>>> HTH
>>>
>>> Yes.. and be sure to go beyond the basic tests.
>>
>> First off, make sure it's running:
>> smartctl -s on -A /dev/disk0   ;for each drive, and using the
>> appropriate /dev/..
>>
>> Then after, it's accumulated some stats:
>> smartctl -A /dev/disk0
>>
>> For a lot of drives, the first line - raw read errors, can be very
>> telling - anything other than 0, and your disk is failing.
>> Start-up-time can be telling, if it's increasing.
>>
>> The thing is, that most drives, except those designed for use in RAID
>> arrays, mask impending disk failures, by re-reading blocks multiple
>> times - they often get the data eventually, but your machine keeps
>> getting slower and slower.
>>
>>
>
> Thanks Miles, and tomás, for your helpful replies.
>
> I apologise for the delay in replying, but I've been away from my desk a
> few days.
>
> I have however been doing some extensive googling, and it would appear
> that the raw read error count is something of a red herring, especially
> when applied to Seagate drives, as these are. Both my drives have quite
> high (in the millions) of RREC; numbers which are precisely matched by the
> Hardware ECC Recovered counts, suggesting that the RREC is merely an
> artifact od HHDs being essentially a mechanical device, being pushed to its
> limits using clever technology. The SMART extended tests reveal no problems.
>
> The Wikipedia entry https://en.wikipedia.org/wiki/S.M.A.R.T. is
> particularly informative in the relative importance of these error counts;
> the RREC can be safely ignored, as somebody else here recently suggested.
>
> So, back to the original problem; I think tomás hit the nail on the head.
> I've re-plugged the SATA cables, to no great effect; I have now ordered a
> couple of new cables, and will see whether that helps.
>
> Thanks again to  all.
>
>
>
>
> --
> Tony van der Hoff        | mailto:tony@vanderhoff.org
> Buckinghamshire, England |
>
>

[toc] | [prev] | [next] | [standalone]

#159524

On 20/10/15 11:22, Ondřej Grover wrote:
> Does this error occur by any chance after resuming from suspended state?

No, this machine doesn't suspend.

But thanks, anyway.


-- 
Tony van der Hoff        | mailto:tony@vanderhoff.org
Buckinghamshire, England |

[toc] | [prev] | [next] | [standalone]

#159530

See below

Tony van der Hoff wrote:
> On 17/10/15 17:47, Miles Fidelman wrote:
>> Dominique Dumont wrote:
>>> On Saturday 17 October 2015 14:15:52 Tony van der Hoff wrote:
>>>> Can anyone please explain what it means, and whether I should be
>>>> worried?
>>> You should check the drive with smartctl.
>>>
>>> See http://www.smartmontools.org/
>>>
>>> HTH
>>>
>> Yes.. and be sure to go beyond the basic tests.
>>
>> First off, make sure it's running:
>> smartctl -s on -A /dev/disk0   ;for each drive, and using the
>> appropriate /dev/..
>>
>> Then after, it's accumulated some stats:
>> smartctl -A /dev/disk0
>>
>> For a lot of drives, the first line - raw read errors, can be very
>> telling - anything other than 0, and your disk is failing.
>> Start-up-time can be telling, if it's increasing.
>>
>> The thing is, that most drives, except those designed for use in RAID
>> arrays, mask impending disk failures, by re-reading blocks multiple
>> times - they often get the data eventually, but your machine keeps
>> getting slower and slower.
>>
>
>
> Thanks Miles, and tomás, for your helpful replies.
>
> I apologise for the delay in replying, but I've been away from my desk 
> a few days.
>
> I have however been doing some extensive googling, and it would appear 
> that the raw read error count is something of a red herring, 
> especially when applied to Seagate drives, as these are. Both my 
> drives have quite high (in the millions) of RREC; numbers which are 
> precisely matched by the Hardware ECC Recovered counts, suggesting 
> that the RREC is merely an artifact od HHDs being essentially a 
> mechanical device, being pushed to its limits using clever technology. 
> The SMART extended tests reveal no problems.
>
> The Wikipedia entry https://en.wikipedia.org/wiki/S.M.A.R.T. is 
> particularly informative in the relative importance of these error 
> counts; the RREC can be safely ignored, as somebody else here recently 
> suggested.

You're missing the point.

As the Wikipedia also points out:
<https://en.wikipedia.org/wiki/S.M.A.R.T.#cite_note-seagate1-2>"Mechanical 
failures account for about 60% of all drive failures." and "Further, 36% 
of drives failed without recording any S.M.A.R.T. error at all, except 
the temperature, meaning that S.M.A.R.T. data alone was of limited 
usefulness in anticipating failures."

Today's disk drives are designed to PROTECT DATA, AND MAINTAIN ACCESS TO 
DATA, until the very moment before the drive fails catastrophically.  
The "Hardware ECC Recovered Count" indicates that:
- there are likely to be problems with the underlying media that the ECC 
is recovering from, that will only get worse over time
- the recovery takes time, hence the reason you system is slowing down - 
the more underlying errors, the more time it takes to recover

I've never found SMART extended tests to be indicative of anything, 
until a disk is nearly dead.  Though 
http://www.z-a-recovery.com/manual/smart.aspx gives a good list of other 
SMART variables that might indicate mechanical failures.

If your drives are a couple of years old, and your machine is getting 
slower, don't engage in wishful thinking - backup and get new drives.

Miles

-- 
In theory, there is no difference between theory and practice.
In practice, there is.   .... Yogi Berra

[toc] | [prev] | [next] | [standalone]

#159326

On Saturday 17 October 2015 14:15:52 Tony van der Hoff wrote:
> Can anyone please explain what it means, and whether I should be worried?

You should check the drive with smartctl.

See http://www.smartmontools.org/

HTH

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

[toc] | [prev] | [next] | [standalone]

#159527

On Sat, Oct 17, 2015 at 02:15:52PM +0100, Tony van der Hoff wrote:
> Hi,
> 
> T'm occasionally getting this message in syslog on my jessie box:
> 
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600489] ata3.00: exception Emask 0x10
> SAct 0x10 SErr 0x400000 action 0x6 frozen
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600501] ata3.00: irq_stat 0x08000000,
> interface fatal error
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600509] ata3: SError: { Handshk }
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600517] ata3.00: failed command:
> WRITE FPDMA QUEUED
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600531] ata3.00: cmd
> 61/c0:20:90:6e:eb/01:00:22:00:00/40 tag 4 ncq 229376 out
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600531]          res
> 40/00:20:90:6e:eb/00:00:22:00:00/40 Emask 0x10 (ATA bus error)
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600538] ata3.00: status: { DRDY }
> Oct 17 12:00:19 tony-lx kernel: [ 8838.600547] ata3: hard resetting link
> Oct 17 12:00:20 tony-lx kernel: [ 8839.092521] ata3: SATA link up 6.0 Gbps
> (SStatus 133 SControl 300)
> Oct 17 12:00:20 tony-lx kernel: [ 8839.099092] ata3.00: configured for
> UDMA/133
> Oct 17 12:00:20 tony-lx kernel: [ 8839.099121] ata3: EH complete
> 
> 
> Can anyone please explain what it means, and whether I should be worried?

To find out if this error is caused by the harddisk or by other components,
I'd suggest moving the disk to a different computer.

If the errors remain, your disk is failing.
Otherwise, swap components one by one.
A good next candidate would be the power supply unit.
Also, check the mainboard capacitors for a bulged top or leakage.

Regards,
Mirko

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web