The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Новая версия утилит для работы со SMART-информацией - Smartmontools 7.0

31.12.2018 02:22

Вышла новая версия пакета smartmontools 7.0, содержащего приложения (smartctl и smartd) для мониторинга и контроля (S)ATA, SCSI/SAS и NVMe дисков, поддерживающих технологию SMART. Поддерживается работа на платформах Linux, FreeBSD, Darwin (macOS), Windows, QNX, OS/2, Solaris, NetBSD и OpenBSD.

Основные изменения, реализованные с момента выхода версии 6.6:

  • smartctl: новые ключи '-j' и '--json[=giosu]' для вывода в формате json. В качестве альтернативы также добавлен формат, удобный для построчного парсинга утилитой grep ('--json=g');
  • smartctl: режим '-l devstat' теперь корректно работает с логами размером более 256 секторов;
  • smartctl: поддержка "SCSI Pending Defects log page" в выводе '-l error';
  • smartctl/NVMe: новый тип устройств '-d sntjmicron' для работы с устройствами JMicron USB NVMe;
  • smartctl/SCSI: множество улучшений, связанных с декодированием log-страниц;
  • smartctl/smartd: переработана работа с невыровненными числами LE и BE;
  • smartctl/FreeBSD: добавлено сканирование устройств NVMe;
  • smartctl/NetBSD: исправлены появившиеся в версии 6.6 регрессии автоопределения устройств, исправлены проблемы на big endian архитектурах;
  • smartctl/Windows: улучшен поиск номера порта CSMI.


  1. Главная ссылка к новости (https://smartmontools.org...)
  2. OpenNews: Новая версия утилит для работы со SMART-информацией - Smartmontools 6.6
  3. OpenNews: Новая версия утилит для работы со SMART-информацией - Smartmontools 6.5
  4. OpenNews: Новая версия утилит для работы со SMART-информацией - Smartmontools 6.4
  5. OpenNews: Новая версия утилит для работы со SMART-информацией - Smartmontools 6.3
  6. OpenNews: Новая версия утилит для работы со SMART-информацией - Smartmontools 6.2
Автор новости: samm
Тип: Программы
Ключевые слова: smartmontools, smart, disk
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (38) Ajax | 1 уровень | Линейный | Раскрыть всё | RSS
  • 1.1, Аноним (1), 14:11, 31/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот бы смену сепаратора для csmi приделали.
     
  • 1.2, Michael Shigorin (ok), 15:02, 31/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Wrote: /usr/src/RPM/RPMS/e2k/smartmontools-7.0-alt1.e2k.rpm
    :)
     
     
  • 2.3, Аноним (-), 15:43, 31/12/2018 [^] [^^] [^^^] [ответить]  
  • +/
    Bunny, is that you?
     
  • 2.10, Аноним (10), 07:24, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Wpope?
     

  • 1.4, СеменСеменыч777 (?), 16:43, 31/12/2018 [ответить] [﹢﹢﹢] [ · · · ]  
  • –10 +/
    чушь это все. все HDD скрывают свои дефекты как могут, на запросы по SMART всегда отвечают "все хорошо, все нормально", а потом умирают без предупреждений.
     
     
  • 2.5, Аноним (5), 17:49, 31/12/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Дык, надо запускать longtest переодически а не ждать чудес
     
     
  • 3.6, Michael Shigorin (ok), 17:54, 31/12/2018 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > Дык, надо запускать longtest переодически а не ждать чудес

    Проблема и впрямь имеет место быть -- примерно с тех пор как поставщики BIOS начали вклёпывать "пужалки" на не-нули... сперва стали прятать заводские дефекты из-за этих гигантских дятлов, ну а затем просто затупили SMART, когда-то бывший полезным.  Это по моим ощущениям и инцидентам, разумеется.

     
  • 2.7, AnonPlus (?), 18:39, 31/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Не думал, что конспирологи даже в такой теме могут быть.
     
     
  • 3.8, Michael Shigorin (ok), 19:10, 31/12/2018 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Не думал, что конспирологи даже в такой теме могут быть.

    Да какая тут конспирология -- просто наблюдений за происходящим с дисками лет за десять-двенадцать может хватить.  Ну и обсуждения с коллегами.

    Возможно, и в статьях тех же гуглосотрудников про вымирание дисков в больших популяциях что-то на эту тему было, уже не помню...

     
  • 3.11, СеменСеменыч777 (?), 11:48, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +5 +/
    > конспирологи

    как будто бы что-то плохое.

    ps: конспирологи говорили с конца 90х годов, что в винде закладки. а мы над ними смеялись.

     
  • 2.9, MirandaUser2 (?), 21:08, 31/12/2018 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Не замечал такого. По значениям (и скорости их изменения)
    Reallocated_Sector_Ct
    Current_Pending_Sector
    Offline_Uncorrectable
    вполне можно вовремя обнаружить проблему. Крайний раз года 3 назад пара WD green вышли из строя, но
    информацию удалось вытащить через ddrescue.
    Но то HDD, а вот на SSD (A-DATA) как раз наблюдал, что в SMART никаких ошибок, а  при этом чтение/запись некоторых секторов не работает. После чего, заменил почти все эти A-DATA на обычный USB flash (в read-only). Рабочего SMART и там, и там нет, при этом USB flash в разы дешевле (это системный диск, объемы до 16GB).
     
     
  • 3.13, Аноним (5), 15:21, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    RTFM: https://superuser.com/a/1022634
     
     
  • 4.20, Michael Shigorin (ok), 20:38, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Самое по существу, как мне кажется: "I would put the time and effort into a frequent back-up solution, rather than frequent testing of the drive".
     
     
  • 5.22, samm (ok), 10:51, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    это типа как "я буду лечить себе ногу вместо того, чтобы пить витамины". Очень глупое взаимоисключение, это даже если вынести за скобки то, что бекап солюшн тоже требует мониторинга, если мы его не аутсорсим.
     
  • 5.23, samm (ok), 10:55, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    заметку писал д-бил, как и 99% "экспертных советов" на подобных сайтах. Никакого изнашивания ни лонг тест ни рейдовский патрол рид не добавляет, так как  обычное чтение - базовая операция винта. Основной износ это обычно start/stop cycles или просто наработка по времени, ни на первое ни на второе чтение поверхности не влияет.

    Более того - чтение даже полезно, так как если у нас есть сектор который читается неуверенно и был прочитан со второго раза (или спасен по ecc) то firmware может его ремапнуть или просто перезаписать.

     
     
  • 6.27, Michael Shigorin (ok), 13:53, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Никакого изнашивания ни лонг тест ни рейдовский патрол рид
    > не добавляет, так как  обычное чтение - базовая операция винта.

    Там о том, что _в принципе_ любое механическое воздействие ускоряет износ (эдак философски).

    И о том, что если уж зачитывать поверхность -- то стоит заодно передать считанное в бэкап.  Тут-то что не так?

    (а что порой стоит как минимум короткий тест гонять, чтоб не поймать уже явочным порядком проблемы с головой/электроникой -- ну да)

     
     
  • 7.31, samm (ok), 23:13, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    нет не ускоряет, так как это не механическое воздействие, а электромагнитное. И уж точно проблемы с кол-вом циклов перезаписи у диска нет
     
  • 7.32, samm (ok), 23:14, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    если мы читаем в бекап - то мы читаем только сектора на которых есть инфа. рейд патрол рид или лонг селф тест позволяют прочесть _все сектора)
     
     
  • 8.33, Michael Shigorin (ok), 00:18, 03/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Резонно спасибо ... текст свёрнут, показать
     
  • 4.37, MirandaUser2 (?), 01:55, 20/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    Это Вы к тому, что нужно время от времени прогонять short/long test?
    Так вот на этом самом проблемном SSD он проходит без ошибок:

    === START OF READ SMART DATA SECTION ===
    SMART Self-test log structure revision number 1
    Num  Test_Description    Status                  Remaining  LifeTime(hours)  LBA_of_first_error
    # 1  Extended offline    Completed without error       00%     37246         -
    # 2  Short offline       Completed without error       00%     37246         -
    # 3  Extended offline    Completed without error       00%      8279         -

    при чтении:

    ~ # dd if=/dev/sdb of=/dev/null bs=32M
    dd: error reading '/dev/sdb': Input/output error
    13+1 records in
    13+1 records out
    464543744 bytes (465 MB, 443 MiB) copied, 2,70164 s, 172 MB/s

    вывод dmesg:

    [477340.154080] ata6.00: exception Emask 0x0 SAct 0x10000 SErr 0x0 action 0x0
    [477340.154083] ata6.00: irq_stat 0x40000008
    [477340.154087] ata6.00: failed command: READ FPDMA QUEUED
    [477340.154094] ata6.00: cmd 60/08:80:30:d8:0d/00:00:00:00:00/40 tag 16 ncq dma 4096 in
                             res 41/40:80:30:d8:0d/00:00:00:00:00/40 Emask 0x409 (media error) <F>
    [477340.154096] ata6.00: status: { DRDY ERR }
    [477340.154098] ata6.00: error: { UNC }
    [477340.154692] ata6.00: configured for UDMA/100
    [477340.154703] sd 5:0:0:0: [sdb] tag#16 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
    [477340.154707] sd 5:0:0:0: [sdb] tag#16 Sense Key : Medium Error [current]
    [477340.154710] sd 5:0:0:0: [sdb] tag#16 Add. Sense: Unrecovered read error - auto reallocate failed
    [477340.154713] sd 5:0:0:0: [sdb] tag#16 CDB: Read(10) 28 00 00 0d d8 30 00 00 08 00
    [477340.154715] print_req_error: I/O error, dev sdb, sector 907312
    [477340.154717] Buffer I/O error on dev sdb, logical block 113414, async page read
    [477340.154728] ata6: EH complete

    P.S. смена шлейфа не меняет ситуацию.

     
  • 3.24, samm (ok), 10:59, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    В SSD нет никаких "настоящих" секторов. Смарт мониторить на ssd не менее а _более_ важно, так как обычно по исчерпанию циклов записи-стирания винт переходит в read only и лучше этот момень поймать мониторингом заранее, а не живым сервисом на проде. Тем более что если у нас 2 ssd в зеркале - то есть отличные шансы что у них этот показатель будет идентичным, ну далее понятно. Что до a-data - я бы вообще не рекомендовал их использовать для чего либо важного, это крайне недорогой oem с соответствующим цене качеством.
     
     
  • 4.38, MirandaUser2 (?), 03:08, 20/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В SSD нет никаких "настоящих" секторов.

    Ну это понятно, но роль SMART'а в моем понимании та же - предоставлять информацию для диагностики и мониторинга состояния накопителя данных.

    > это крайне недорогой oem с соответствующим цене качеством.

    я собственно и брал его как компактный, негреющийся накопитель для тех данных которые несложно восстановить. Как оказалось, для моих задач USB flash подходит лучше.

     
  • 2.17, samm (ok), 19:47, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > чушь это все.

    нет. чушь - это ваш пост
    > все HDD скрывают свои дефекты как могут

    нет.

    > на запросы по SMART всегда отвечают "все хорошо, все нормально"

    такого ответа нет. есть - атрибуты и селфтесты. из них можно делать вывод. или нет.
    > а потом умирают без предупреждений.

    ну если не уметь пользоваться инструментами - то так и выходит, да

     
  • 2.35, Catwoolfii (ok), 10:06, 03/01/2019 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что касается ssd, то с чипами памяти действительно может быть все хорошо, при этом может тупо сдохнуть контроллер. Вот у меня один такой сдох - разобрал, прозвонил транзисторы, несколько звенят. Проблема заключается в некачественной элементной базе.
     

  • 1.12, Аноним (12), 13:38, 01/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В последнее время на дисках встречаю что в Current_Pending_Sector от одного до двух значений увеличивается через какое то время. Если скачками не увеличивается после этого имеет смысл менять диск?
     
     
  • 2.14, Аноним (5), 15:23, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    если диск начал 'сыпаться' - его нужно менять, если конечно важно сохранить данные
     
  • 2.18, samm (ok), 19:52, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    как минимум сразу стоит сделать long selftest
     
     
  • 3.28, Аноним (28), 15:07, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    long selftest нормально при этом проходит
     
  • 2.29, . (?), 16:19, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    если диск единственный и бэкапы делаются реже чем раз в минуту - да, менять, не должно у исправного диска быть никаких pending sectors.

    после этого пройти по всей поверхности тотальным write-verify, посмотреть снова на pending & relocated и либо сделать из него дискету, либо отправить туда, где отказ диска и последующая переустановка обойдутся дешевле покупки нового такого же.

     

  • 1.15, th3m3 (ok), 18:06, 01/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    В своё время хотел заняться этой приблудой, но когда прочитал отзывы людей - когда эти ваши Смарты показывали, что всё ок, а диск внезапно накрывался. Сделал выводы, что проще не тратить время на это всё.
     
     
  • 2.16, samm (ok), 19:43, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +3 +/
    очень глупый вывод, да. А читать надо не "отзывы людей с опеннета" а нормальные стади, ссылки на которые есть с вебсайта проекта
     
  • 2.19, Michael Shigorin (ok), 20:11, 01/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    > В своё время хотел заняться этой приблудой, но когда прочитал отзывы
    > людей - когда эти ваши Смарты показывали, что всё ок, а диск
    > внезапно накрывался.

    Есть нюанс: _полагаться_ на нынешний SMART не получается, но уж если долетело -- в любом разе стоит обратить внимание.

    smartd(8) почтой напишет, если что.

     
     
  • 3.21, samm (ok), 10:49, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    полагаться надо только на бекапы и (не или!) стораджи с избыточностью, всякие там рейды, zfs и вот это все. Но смарт при этом - прекрасный помощник, вот недавно мне от смартд прилетело на 2 винта, которые raid patrol read считал нормальными и я их заменил до возникновения каких либо проблем.
     
     
  • 4.25, . (?), 12:43, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > полагаться надо только на бекапы и (не или!) стораджи с избыточностью

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

    > вот недавно мне от смартд прилетело на 2 винта, которые raid patrol read считал
    > нормальными и я их заменил до возникновения каких либо проблем.

    молодец. Главное ж - верить! В то что проблемы с ними хоть как-то более вероятны, чем с любыми другими. А то я вот _десять_ сцуко лет держал диск с напрочь умершим смартом, а теперь вот пришлось демонтировать - ну просто нет места для терабайтников, нивлизэ. Как дискета, к сожалению, не послужит, хотя мог бы - во-первых горячий, во вторых модные-современные системы, действительно, завидев его начинают визжать как недорезанный хряк, либо полностью блокируя работу, либо сильно мешаясь.
    Куда, говоришь, выкинул? Мне бы вот парочка хороших дисков на халяву-то пригодилась...

     
     
  • 5.26, samm (ok), 12:47, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • +/
    послушайте, я смиявсь про "админа локалхоста". Вы бы посмотрели мой профиль для начала, ага.

    Выкинул в контейнер для электронного мусора, тут такие есть. местные бомжи иногда их ломают, так что можете вместе с ними, мне не жалко.

     
     
  • 6.30, . (?), 16:35, 02/01/2019 [^] [^^] [^^^] [ответить]  
  • –2 +/
    да плевать мне на сопли пузырем и пальцы веером - раз болтает до сих пор человек о бэкапах и рейдах, дальше неинтересно про него ничего знать.

    > Выкинул в контейнер для электронного мусора

    а, ну правильно, экологичненько же ж, чо. Если местные бомжи (хм, а что они то делают с содержимым - продают на ebay?) не украдут - уедет в африку, там нигры расковыряют на детальки - винтики направо, ляминь налево, остальное в костер.

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

     

  • 1.34, Аноним (34), 00:55, 03/01/2019 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    >smartctl: новые ключи '-j' и '--json[=giosu]' для вывода в формате json.

    да ладно!!! джва года ждал :)

     
     
  • 2.36, samm (ok), 11:33, 03/01/2019 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну там и работы было куча :) Зато в итоге там не 1 json, а целых дофига )
     
     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Слёрм
    Inferno Solutions
    Hosting by Ihor
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2019 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру