Вышла новая версия пакета smartmontools 7.0 (https://www.smartmontools.org/), содержащего приложения (smartctl и smartd) для мониторинга и контроля (S)ATA, SCSI/SAS и NVMe дисков, поддерживающих технологию SMART. Поддерживается работа на платформах Linux, FreeBSD, Darwin (macOS), Windows, QNX, OS/2, Solaris, NetBSD и OpenBSD.
Основные изменения, реализованные с момента выхода версии 6.6 (https://www.opennet.dev/opennews/art.shtml?num=47514):
- smartctl: новые ключи '-j' and '--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.
URL: https://smartmontools.org
Новость: https://www.opennet.dev/opennews/art.shtml?num=49879
Вот бы смену сепаратора для csmi приделали.
Wrote: /usr/src/RPM/RPMS/e2k/smartmontools-7.0-alt1.e2k.rpm
:)
Bunny, is that you?
Wpope?
чушь это все. все HDD скрывают свои дефекты как могут, на запросы по SMART всегда отвечают "все хорошо, все нормально", а потом умирают без предупреждений.
Дык, надо запускать longtest переодически а не ждать чудес
> Дык, надо запускать longtest переодически а не ждать чудесПроблема и впрямь имеет место быть -- примерно с тех пор как поставщики BIOS начали вклёпывать "пужалки" на не-нули... сперва стали прятать заводские дефекты из-за этих гигантских дятлов, ну а затем просто затупили SMART, когда-то бывший полезным. Это по моим ощущениям и инцидентам, разумеется.
Не думал, что конспирологи даже в такой теме могут быть.
> Не думал, что конспирологи даже в такой теме могут быть.Да какая тут конспирология -- просто наблюдений за происходящим с дисками лет за десять-двенадцать может хватить. Ну и обсуждения с коллегами.
Возможно, и в статьях тех же гуглосотрудников про вымирание дисков в больших популяциях что-то на эту тему было, уже не помню...
> конспирологикак будто бы что-то плохое.
ps: конспирологи говорили с конца 90х годов, что в винде закладки. а мы над ними смеялись.
Не замечал такого. По значениям (и скорости их изменения)
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).
RTFM: https://superuser.com/a/1022634
Самое по существу, как мне кажется: "I would put the time and effort into a frequent back-up solution, rather than frequent testing of the drive".
это типа как "я буду лечить себе ногу вместо того, чтобы пить витамины". Очень глупое взаимоисключение, это даже если вынести за скобки то, что бекап солюшн тоже требует мониторинга, если мы его не аутсорсим.
заметку писал д-бил, как и 99% "экспертных советов" на подобных сайтах. Никакого изнашивания ни лонг тест ни рейдовский патрол рид не добавляет, так как обычное чтение - базовая операция винта. Основной износ это обычно start/stop cycles или просто наработка по времени, ни на первое ни на второе чтение поверхности не влияет.Более того - чтение даже полезно, так как если у нас есть сектор который читается неуверенно и был прочитан со второго раза (или спасен по ecc) то firmware может его ремапнуть или просто перезаписать.
> Никакого изнашивания ни лонг тест ни рейдовский патрол рид
> не добавляет, так как обычное чтение - базовая операция винта.Там о том, что _в принципе_ любое механическое воздействие ускоряет износ (эдак философски).
И о том, что если уж зачитывать поверхность -- то стоит заодно передать считанное в бэкап. Тут-то что не так?
(а что порой стоит как минимум короткий тест гонять, чтоб не поймать уже явочным порядком проблемы с головой/электроникой -- ну да)
нет не ускоряет, так как это не механическое воздействие, а электромагнитное. И уж точно проблемы с кол-вом циклов перезаписи у диска нет
если мы читаем в бекап - то мы читаем только сектора на которых есть инфа. рейд патрол рид или лонг селф тест позволяют прочесть _все сектора)
> если мы читаем в бекап - то мы читаем только сектора на
> которых есть инфа. рейд патрол рид или лонг селф тест позволяют
> прочесть _все сектора_Резонно; спасибо.
Это Вы к тому, что нужно время от времени прогонять 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 completeP.S. смена шлейфа не меняет ситуацию.
В SSD нет никаких "настоящих" секторов. Смарт мониторить на ssd не менее а _более_ важно, так как обычно по исчерпанию циклов записи-стирания винт переходит в read only и лучше этот момень поймать мониторингом заранее, а не живым сервисом на проде. Тем более что если у нас 2 ssd в зеркале - то есть отличные шансы что у них этот показатель будет идентичным, ну далее понятно. Что до a-data - я бы вообще не рекомендовал их использовать для чего либо важного, это крайне недорогой oem с соответствующим цене качеством.
> В SSD нет никаких "настоящих" секторов.Ну это понятно, но роль SMART`а в моем понимании та же - предоставлять информацию для диагностики и мониторинга состояния накопителя данных.
> это крайне недорогой oem с соответствующим цене качеством.
я собственно и брал его как компактный, негреющийся накопитель для тех данных которые несложно восстановить. Как оказалось, для моих задач USB flash подходит лучше.
> чушь это все.нет. чушь - это ваш пост
> все HDD скрывают свои дефекты как могутнет.
> на запросы по SMART всегда отвечают "все хорошо, все нормально"
такого ответа нет. есть - атрибуты и селфтесты. из них можно делать вывод. или нет.
> а потом умирают без предупреждений.ну если не уметь пользоваться инструментами - то так и выходит, да
Что касается ssd, то с чипами памяти действительно может быть все хорошо, при этом может тупо сдохнуть контроллер. Вот у меня один такой сдох - разобрал, прозвонил транзисторы, несколько звенят. Проблема заключается в некачественной элементной базе.
В последнее время на дисках встречаю что в Current_Pending_Sector от одного до двух значений увеличивается через какое то время. Если скачками не увеличивается после этого имеет смысл менять диск?
если диск начал 'сыпаться' - его нужно менять, если конечно важно сохранить данные
как минимум сразу стоит сделать long selftest
long selftest нормально при этом проходит
если диск единственный и бэкапы делаются реже чем раз в минуту - да, менять, не должно у исправного диска быть никаких pending sectors.после этого пройти по всей поверхности тотальным write-verify, посмотреть снова на pending & relocated и либо сделать из него дискету, либо отправить туда, где отказ диска и последующая переустановка обойдутся дешевле покупки нового такого же.
В своё время хотел заняться этой приблудой, но когда прочитал отзывы людей - когда эти ваши Смарты показывали, что всё ок, а диск внезапно накрывался. Сделал выводы, что проще не тратить время на это всё.
очень глупый вывод, да. А читать надо не "отзывы людей с опеннета" а нормальные стади, ссылки на которые есть с вебсайта проекта
> В своё время хотел заняться этой приблудой, но когда прочитал отзывы
> людей - когда эти ваши Смарты показывали, что всё ок, а диск
> внезапно накрывался.Есть нюанс: _полагаться_ на нынешний SMART не получается, но уж если долетело -- в любом разе стоит обратить внимание.
smartd(8) почтой напишет, если что.
полагаться надо только на бекапы и (не или!) стораджи с избыточностью, всякие там рейды, zfs и вот это все. Но смарт при этом - прекрасный помощник, вот недавно мне от смартд прилетело на 2 винта, которые raid patrol read считал нормальными и я их заменил до возникновения каких либо проблем.
> полагаться надо только на бекапы и (не или!) стораджи с избыточностьюкак легка и приятна жизнь админов локалхоста, где и бэкапать-то, на деле, нечего - порнухи обратно понакачаешь свежей...
> вот недавно мне от смартд прилетело на 2 винта, которые raid patrol read считал
> нормальными и я их заменил до возникновения каких либо проблем.молодец. Главное ж - верить! В то что проблемы с ними хоть как-то более вероятны, чем с любыми другими. А то я вот _десять_ сцуко лет держал диск с напрочь умершим смартом, а теперь вот пришлось демонтировать - ну просто нет места для терабайтников, нивлизэ. Как дискета, к сожалению, не послужит, хотя мог бы - во-первых горячий, во вторых модные-современные системы, действительно, завидев его начинают визжать как недорезанный хряк, либо полностью блокируя работу, либо сильно мешаясь.
Куда, говоришь, выкинул? Мне бы вот парочка хороших дисков на халяву-то пригодилась...
послушайте, я смиявсь про "админа локалхоста". Вы бы посмотрели мой профиль для начала, ага.Выкинул в контейнер для электронного мусора, тут такие есть. местные бомжи иногда их ломают, так что можете вместе с ними, мне не жалко.
да плевать мне на сопли пузырем и пальцы веером - раз болтает до сих пор человек о бэкапах и рейдах, дальше неинтересно про него ничего знать.> Выкинул в контейнер для электронного мусора
а, ну правильно, экологичненько же ж, чо. Если местные бомжи (хм, а что они то делают с содержимым - продают на ebay?) не украдут - уедет в африку, там нигры расковыряют на детальки - винтики направо, ляминь налево, остальное в костер.
(это, как и с бэкапами и рейдами, если что, не повод примерно так же и не делать, если цена диска для тебя семечки - и неважно, смарт что-то пискнул, или молчит а скорость линейного чтения почему-то уменьшилась без внешних причин - но это про экономику, а не про надежность технологий)
>smartctl: новые ключи '-j' и '--json[=giosu]' для вывода в формате json.да ладно!!! джва года ждал :)
Ну там и работы было куча :) Зато в итоге там не 1 json, а целых дофига )