Т.е. сетевые интерфейсы можно обзывать не-ascii символами? И какой [censored] это придумал? Блин, шо винда, шо *никсы - локализуют то, что не надо, что надо - не локализуют.
Во-первых, использовать smartctl для nvme - это спорно, мягко говоря. Можно, но SMART - это фича SATA. А nvme, это, мягко говоря, другой интерфейс. Мягко говоря.
Это всё равно, как требовать от smartctl всё знать и уметь про sas-диски.
Я вот зашёл на wiki у smartmontools и там сказано "Smartmontools supports NVMe starting from version 6.5. Please note, that currently NVMe support is considered as experimental. "
> Можно, но SMART - это фича SATA. А nvme, это, мягко говоря, другой интерфейс.
Мягко говоря, на интерфейс начхать. ATAPI/SATA/SAS/NVME/... один фиг блочное устройство, и вполне логично было бы иметь единый способ спрашивать "а скока там осыпавшихся блоков, не пора ли менять железку?". Т.е. как минимум атрибуты 5, 174, 194, 196, 197, 198 вполне универсальны для мониторинга любых типов подобных устройств, есть там внутре блины или нет, а за всякие vendor-specific, торчащие наружу (если для них нет открытой документации) вендорам следует рубить руки ссаными тряпками.
Прости меня, какие атрибуты универсальны для scsi-сканера? А для tape-устройства?
Я понимаю, что тебе хочется всё под одну гребёнку. Linux и так тебе ВСЁ под одну гребёнку, так что ты не замечаешь разницы между SD-карточкой, usb mass storage, sata-ssd, iscsi-устройством и high-end sas-полкой за двумя рейдами с избыточностью, но есть граница между универсальностью и фичами.
Ты не можешь спрашивать рейд-контроллер, подключенный к полке с multipath о тех же параметрах, о которых ты спрашиваешь диск.
Ну, как раз, например, для полки что-то шмарт-образное и имело б смысл. Отвечает о битых секторах "вообще" - пора проверять составляющие массив устройства. Температуру сообщать для самого горячего устройства в полке. И т.п. SCSI-сканеры, кажется, уже вымерли. И я под блочными устройствами выше имел в виду только storage, разумеется. Для ленты понятие битых блоков вполне имеет смысл, температуры потрохов, с некоторой натяжкой - тоже. В лентожевалках вполне есть чему перегреваться. Т.е. обобщённый интерфейс мониторинга с атрибутами "у вас косяк примерно такого типа" однозначно был бы полезен. Причем как раз простой, как обрезок от шмарта, а не snmp какое-нибудь архиразвесистое.
Ну, вот у производителей рейдов (например, у LSI) своё видение метрик, требующих внимания операторов. Например, надо отдавать метрику для unassigned диска? (напомню, что в хост-систему видна одна буква для одного массива, а отдельных дисков не видно). А для hostspare? А для shared hotspare куда засчитывать?
А ещё LSI позволяет небольшое количество ошибок чтения с одного диска и не выбраковывает его за это до тех пор, пока данные в безопасности. Там порог по rate'у.
... Вообще, проблема, про которую ты говоришь, у крупных вендоров давно решена. Тот же idrac у делла говорит обо всех отказах всех устройств в системе вне зависимости от метода подключения. (хотя и он сфейлится на кривой sd'шке...).
И у каждого, небось, свой собственный, ни с кем не совместимый изврат? В виде закрытой фирмвари, софтины с аппаратным ключиком, дабы гнусный пират обломился?
Изврат там ещё тот, но, на удивление, по стандарту. Redfish новый, wsm старый. Пользоваться им ужасно, но стандарт-с.
А фирмварь у них, разумеется, проприетарная. Этим они не сильно отличаются от любой другой железки (начиная с SSD и заканчивая thunderbolt-контроллером).
Блин, шо винда, шо *никсы - локализуют то, что не надо, что надо - не локализуют.
Reply
Это всё равно, как требовать от smartctl всё знать и уметь про sas-диски.
Я вот зашёл на wiki у smartmontools и там сказано "Smartmontools supports NVMe starting from version 6.5. Please note, that currently NVMe support is considered as experimental. "
А так, вообще-то, есть nvme-cli.
Reply
Мягко говоря, на интерфейс начхать. ATAPI/SATA/SAS/NVME/... один фиг блочное устройство, и вполне логично было бы иметь единый способ спрашивать "а скока там осыпавшихся блоков, не пора ли менять железку?".
Т.е. как минимум атрибуты 5, 174, 194, 196, 197, 198 вполне универсальны для мониторинга любых типов подобных устройств, есть там внутре блины или нет, а за всякие vendor-specific, торчащие наружу (если для них нет открытой документации) вендорам следует рубить руки ссаными тряпками.
Reply
Я понимаю, что тебе хочется всё под одну гребёнку. Linux и так тебе ВСЁ под одну гребёнку, так что ты не замечаешь разницы между SD-карточкой, usb mass storage, sata-ssd, iscsi-устройством и high-end sas-полкой за двумя рейдами с избыточностью, но есть граница между универсальностью и фичами.
Ты не можешь спрашивать рейд-контроллер, подключенный к полке с multipath о тех же параметрах, о которых ты спрашиваешь диск.
Reply
SCSI-сканеры, кажется, уже вымерли. И я под блочными устройствами выше имел в виду только storage, разумеется.
Для ленты понятие битых блоков вполне имеет смысл, температуры потрохов, с некоторой натяжкой - тоже. В лентожевалках вполне есть чему перегреваться.
Т.е. обобщённый интерфейс мониторинга с атрибутами "у вас косяк примерно такого типа" однозначно был бы полезен.
Причем как раз простой, как обрезок от шмарта, а не snmp какое-нибудь архиразвесистое.
Reply
А ещё LSI позволяет небольшое количество ошибок чтения с одного диска и не выбраковывает его за это до тех пор, пока данные в безопасности. Там порог по rate'у.
... Вообще, проблема, про которую ты говоришь, у крупных вендоров давно решена. Тот же idrac у делла говорит обо всех отказах всех устройств в системе вне зависимости от метода подключения. (хотя и он сфейлится на кривой sd'шке...).
Reply
В виде закрытой фирмвари, софтины с аппаратным ключиком, дабы гнусный пират обломился?
Reply
А фирмварь у них, разумеется, проприетарная. Этим они не сильно отличаются от любой другой железки (начиная с SSD и заканчивая thunderbolt-контроллером).
Reply
Leave a comment