LINUX.ORG.RU
решено ФорумAdmin

[непонятно] smartd игнорирует атрибуты?

 


0

0

Имеем настроенный smartd. Недавно увеличился счётчик

199 UDMA_CRC_Error_Count

с 1 до 5 (ошибки при передаче по интерфейсному кабелю). Кабель я, конечно, сменил, но замечено это происшествие было по чистой случайности, т.к. smartd тупо не сообщил об ошибках. Это я тупой или просто 199 не считается важным?

Вот конфиг:

gotf ~ % egrep -v '^#|^$' /etc/smartd.conf 
/dev/disk/by-id/scsi-SATA_ST3500418AS_9VMEEJPA \
    -d sat \ # use scsi-to-ata interface
    -H \ # overall health
    -f \ # check all attribute types
    -I 1 -I 4 -I 7 -I 9 -I 12 -I 190 -I 194 -I 195 -I 240 \ # ignore'em
    -t \ # look for difference beetwen two checks
    -l selftest -l error \ # control this logs
    -C 197 \ # check if current pending sector is more than zero
    -U 198 \ # same for offine uncorrectable
    -m root \ # mailto
    -W 0,45,50 
/dev/disk/by-id/scsi-SATA_ST3500418AS_9VMKF0CW \
    -d sat \ # use scsi-to-ata interface
    -H \ # overall health
    -f \ # check all attribute types
    -I 1 -I 4 -I 7 -I 9 -I 12 -I 190 -I 194 -I 195 -I 240 \ # ignore'em
    -t \ # look for difference beetwen two checks
    -l selftest -l error \ # control this logs
    -C 197 \ # check if current pending sector is more than zero
    -U 198 \ # same for offine uncorrectable
    -m root \ # mailto
    -W 0,45,50

Тестовые сообщения доходят, так что проблема не в доставке. Читал об опции -v, но это не оно, по-моему.

★★★★★

> 199 UDMA_CRC_Error_Count

с 1 до 5

Ви шутите или издеваетесь?)

Device Model: ST380811AS

9 Power_On_Hours 0x0032 088 088 000 Old_age Always - 11218

199 UDMA_CRC_Error_Count 0x003e 200 194 000 Old_age Always - 6913

При этом винт помирать явно не собирается. На одном RAID1 из сигейтов (ок. 2 лет в работе) 199-й атрибут вообще девятизначными числами отображается. И ничего, всё пашет) Это, вообще, не критический атрибут, особенно на сигейтах.

nbw ★★★
()
Ответ на: комментарий от nbw

А вот тут

http://kb.acronis.com/content/9135

написано, в частности, что

Although degradation of this parameter can be an indicator of drive aging and/or potential electromechanical problems, it does not directly indicate imminent drive failure.

it does not directly indicate imminent drive failure.

Так что, традиционно

Regular backup is recommended.

а, в остальном, нет причин для беспокойства) И, да, ни на одной из моих машин SMART не кричит при возрастании (по крайней мере, умеренном) значения этого атрибута. Наверное, и у вас все правильно и так и должно быть.

nbw ★★★
()
Ответ на: комментарий от nbw

>> Ви шутите или издеваетесь?)

Да вроде нет. Тут такое дело — при этой ошибке в syslog упало:

Mar  8 17:43:53 persephone kernel: [  319.090595] ata1: hard resetting link
Mar  8 17:43:54 persephone kernel: [  319.572044] ata1: applying SB600 PMP SRST workaround and retrying
Mar  8 17:43:54 persephone kernel: [  319.736046] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar  8 17:43:54 persephone kernel: [  319.737108] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:43:54 persephone kernel: [  319.738336] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:43:54 persephone kernel: [  319.738340] ata1.00: configured for UDMA/133
Mar  8 17:43:54 persephone kernel: [  319.738354] ata1: EH complete
Mar  8 17:44:02 persephone kernel: [  327.820410] ata1: hard resetting link
Mar  8 17:44:03 persephone kernel: [  328.304032] ata1: applying SB600 PMP SRST workaround and retrying
Mar  8 17:44:03 persephone kernel: [  328.468051] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar  8 17:44:03 persephone kernel: [  328.469118] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:44:03 persephone kernel: [  328.470345] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:44:03 persephone kernel: [  328.470349] ata1.00: configured for UDMA/133
Mar  8 17:44:03 persephone kernel: [  328.470360] ata1: EH complete
Mar  8 17:45:03 persephone kernel: [  389.116534] ata1: hard resetting link
Mar  8 17:45:04 persephone kernel: [  389.600033] ata1: applying SB600 PMP SRST workaround and retrying
Mar  8 17:45:04 persephone kernel: [  389.764040] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Mar  8 17:45:04 persephone kernel: [  389.765104] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:45:04 persephone kernel: [  389.766333] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:45:04 persephone kernel: [  389.766336] ata1.00: configured for UDMA/133
Mar  8 17:45:04 persephone kernel: [  389.766349] ata1: EH complete
Mar  8 17:45:49 persephone kernel: [  434.708225] ata1: limiting SATA link speed to 1.5 Gbps
Mar  8 17:45:49 persephone kernel: [  434.708259] ata1: hard resetting link
Mar  8 17:45:50 persephone kernel: [  435.192043] ata1: applying SB600 PMP SRST workaround and retrying
Mar  8 17:45:50 persephone kernel: [  435.356038] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Mar  8 17:45:50 persephone kernel: [  435.357108] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:45:50 persephone kernel: [  435.358336] ata1.00: SB600 AHCI: limiting to 255 sectors per cmd
Mar  8 17:45:50 persephone kernel: [  435.358340] ata1.00: configured for UDMA/133
Mar  8 17:45:50 persephone kernel: [  435.358353] ata1: EH complete

что слегка меня беспокоит. А при первой такой ошибке случилась незаметная рассинхронизация массива.

>> Это, вообще, не критический атрибут, особенно на сигейтах.

У меня только они, но только на одном больше нуля (на старых не помню, лень втыкать).

GotF ★★★★★
() автор топика
Ответ на: комментарий от nbw

>>> Regular backup is recommended.

RAID1 + бэкапы, поэтому беспокойство весьма условное.

И, да, ни на одной из моих машин SMART не кричит при возрастании (по крайней мере, умеренном) значения этого атрибута. Наверное, и у вас все правильно и так и должно быть.

Спасибо, видимо, это действительно нормально.

GotF ★★★★★
() автор топика
Ответ на: комментарий от GotF

>> при этой ошибке

При четырёх. Как раз видно их все четыре в логе.

GotF ★★★★★
() автор топика
Ответ на: комментарий от GotF

Рассинхронизация случилась, очевидно, при

[ 434.708259] ata1: hard resetting link

, совпавшим с операцией записи. Не страшно, но неприятно.

У меня только они

Вот это страшно) Если такие приключения продолжатся, и будут лавинообразно нарастать, сто'ит, ИМХО, избавится от винта.

nbw ★★★
()
Ответ на: комментарий от GotF

> видимо, это действительно нормально.

Это было бы нормально, если бы не отражалось на синхронизации массива. Хард, кусок SMART'а которого приведён выше, тоже работает в массиве, но ведёт в этом плане себя адекватно. Так что, беру свои слова про «нормальность» обратно, раз на раз не приходится; присмотритесь к нему повнимательнее.

nbw ★★★
()
Ответ на: комментарий от nbw

>> Если такие приключения продолжатся, и будут лавинообразно нарастать, сто'ит, ИМХО, избавится от винта.

Да это не проблема, в случае чего. У меня всё же подозрение на кабель, старый он очень. Посмотрим, что будет с новым.

GotF ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.