• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

Smartmon zeigt exit 64 bei einem Laufwerk

GwenDragon

Registered User
Seite heute morgen wirft smartmon auf meinem Hetzner-Server EQ4 (Debian 7) für /dev/sdb immer einen exit 64.
Es ist eine Seagate Barracuda 7200.12 (ST3750528AS) in einem Raid.

Code:
root@****** ~ # cat /proc/mdstat
Personalities : [raid1]
md2 : active raid1 sda3[0] sdb3[1]
      723526336 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]
      523968 blocks super 1.2 [2/2] [UU]

md0 : active (auto-read-only) raid1 sda1[0] sdb1[1]
      8384448 blocks super 1.2 [2/2] [UU]
        resync=PENDING

unused devices: <none>

Smartvalues:
Code:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   113   099   006    Pre-fail  Always       -       51986686
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       22
  5 Reallocated_Sector_Ct   0x0033   092   092   036    Pre-fail  Always       -       328
  7 Seek_Error_Rate         0x000f   074   060   030    Pre-fail  Always       -       47499116936
  9 Power_On_Hours          0x0032   065   065   000    Old_age   Always       -       30815
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       11
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   071   071   000    Old_age   Always       -       29
188 Command_Timeout         0x0032   100   100   000    Old_age   Always       -       0
189 High_Fly_Writes         0x003a   099   099   000    Old_age   Always       -       1
190 Airflow_Temperature_Cel 0x0022   065   060   045    Old_age   Always       -       35 (Min/Max 32/39)
194 Temperature_Celsius     0x0022   035   040   000    Old_age   Always       -       35 (0 25 0 0)
195 Hardware_ECC_Recovered  0x001a   034   008   000    Old_age   Always       -       51986686
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       74805445425280
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       4010502448
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       3813234146

Auffällig ist wiederkehrend:
Code:
SMART Error Log Version: 1
ATA Error Count: 18 (device log contains only the most recent five errors)
	CR = Command Register [HEX]
	FR = Features Register [HEX]
	SC = Sector Count Register [HEX]
	SN = Sector Number Register [HEX]
	CL = Cylinder Low Register [HEX]
	CH = Cylinder High Register [HEX]
	DH = Device/Head Register [HEX]
	DC = Device Command Register [HEX]
	ER = Error register [HEX]
	ST = Status register [HEX]
Powered_Up_Time is measured from power on, and printed as
DDd+hh:mm:SS.sss where DD=days, hh=hours, mm=minutes,
SS=sec, and sss=millisec. It "wraps" after 49.710 days.

Error 18 occurred at disk power-on lifetime: 30810 hours (1283 days + 18 hours)
  When the command that caused the error occurred, the device was active or idle.

  After command completion occurred, registers were:
  ER ST SC SN CL CH DH
  -- -- -- -- -- -- --
  40 51 00 ff ff ff 0f  Error: UNC at LBA = 0x0fffffff = 268435455

  Commands leading to the command that caused the error were:
  CR FR SC SN CL CH DH DC   Powered_Up_Time  Command/Feature_Name
  -- -- -- -- -- -- -- --  ----------------  --------------------
  60 00 80 ff ff ff 4f 00  42d+04:10:51.917  READ FPDMA QUEUED
  27 00 00 00 00 00 e0 00  42d+04:10:51.913  READ NATIVE MAX ADDRESS EXT
  ec 00 00 00 00 00 a0 00  42d+04:10:51.912  IDENTIFY DEVICE
  ef 03 46 00 00 00 a0 00  42d+04:10:51.912  SET FEATURES [Set transfer mode]
  27 00 00 00 00 00 e0 00  42d+04:10:51.912  READ NATIVE MAX ADDRESS EXT

dmesg zeigt (Ausscnitt) mehrfache:
Code:
[1168923.883889] ata2.00: exception Emask 0x0 SAct 0x400 SErr 0x0 action 0x0
[1168923.883924] ata2.00: irq_stat 0x40000008
[1168923.883952] ata2.00: failed command: READ FPDMA QUEUED
[1168923.883985] ata2.00: cmd 60/00:50:00:5b:25/01:00:47:00:00/40 tag 10 ncq 131072 in
[1168923.883987]          res 41/40:00:4e:5b:25/00:01:47:00:00/00 Emask 0x409 (media error) <F>
[1168923.884082] ata2.00: status: { DRDY ERR }
[1168923.884108] ata2.00: error: { UNC }
[1168924.020839] ata2.00: configured for UDMA/133
[1168924.020877] ata2: EH complete

ist die HD defekt?
 
Last edited by a moderator:
Die ist sogar sehr kaputt. :) Hat ja auch schon viele reallozierte Sektoren. Ich würde sie zunächst mal aus dem RAID werfen, da die Hänger der Platte (siehe Kernel-Log) jedes mal dein gesamtes System blockieren, bis der Kernel schließlich aufgibt und den Timeout meldet.

Anbei: Das ist ein typisches Verhalten der Desktopfestplatten. Serverfestplatten gehen oftmals einfach aus, ohne noch wochen- oder monatelang regelmäßig Ärger zu machen. Ein RAID-Controller hätte die HDD aber vermutlich schon aus dem Verbund geworfen.
 
Danke für nützliche Hinweise. ;)
Ich dachte erst, das ist ein Softwarefehler wegen der meldung READ FPDMA QUEUED

Ich habe jetzt die Platte tauschen lassen.

Dann werde ich mal brav grub + mbr restaurieren und das Raid syncen :rolleyes:
 
Anbei: Das ist ein typisches Verhalten der Desktopfestplatten. Serverfestplatten gehen oftmals einfach aus, ohne noch wochen- oder monatelang regelmäßig Ärger zu machen.
Von Seagate und Toshiba hatte ich das auch schon bei Server-grade Festplatten. Wobei zumindest Seagate erfahrungsgemäß eher allgemein Schrott- und nicht Server-grade ist.
Pauschal kann man das also nicht sagen, zumal einige Hersteller Serverfestplatten schlicht durch einen leicht veränderten Kopf bauen welcher weniger Load-Cycles aushält aber dafür mehr Bewegungen.
 
Von Seagate und Toshiba hatte ich das auch schon bei Server-grade Festplatten. Wobei zumindest Seagate erfahrungsgemäß eher allgemein Schrott- und nicht Server-grade ist.
+1 Schade das es hier keine "Danke" Buttons gibt.

In meiner "Müll und nicht wichtig" NAS sind zwei Seagate Enterprise Platten die schon vor einem halben Jahr hätten aufhören müssen zu drehen wenn es nach den SMART-Werten und Performance geht.

http://pastebin.com/6WF3dWd9
http://pastebin.com/BiCE1tsJ

:D
 
Last edited by a moderator:
Wieso? Bis auf die acht reallozierten Sektoren bei der einen Platte sehen die noch recht gesund aus. Nicht alle SMART-Werte sind bei jedem Hersteller gleich zu interpretieren bzw. teilweise sind sie sogar absolut bedeutungslos.
 
Wieso? Bis auf die acht reallozierten Sektoren bei der einen Platte sehen die noch recht gesund aus. Nicht alle SMART-Werte sind bei jedem Hersteller gleich zu interpretieren bzw. teilweise sind sie sogar absolut bedeutungslos.

Mh, hast recht. hab mich nochmal eingelesen was seagate smart angeht. Trotzdem hört man meist nichts gutes. Die desktopplatten sind aber definitiv nicht so prikelnd. das weiß ich aus heimerfahrung.
 
Wieso? Bis auf die acht reallozierten Sektoren bei der einen Platte sehen die noch recht gesund aus.
Wenn dem wirklich so ist, dass die Platte noch brauchbar ist.
Dafür würde mich dann regelmäßig das Monitoring annörgeln, wenn ich die Platte dran gelassen hätte.

Nicht alle SMART-Werte sind bei jedem Hersteller gleich zu interpretieren bzw. teilweise sind sie sogar absolut bedeutungslos.
Und deswegen haben ich auch hier noch gefragt.
Denn hier gibt es Leute, die täglich als Admins mit Server-HDs zu tun haben und mehr wissen als ich. Ich kann ja nicht auch noch jede Hardware kennen. :eek:

/EDIT: Ach so, ich war wohl nicht gemeint.
 
Last edited by a moderator:
Nein, du warst nicht gemeint, aber auch MadMakz wollte ich nicht "anpflaumen". Ich wollte lediglich mein Wissen teilen... :)
 
Back
Top