smartctl и smartmontools: Пълното ръководство за наблюдение на здравето на дискове в Linux

smartctl е основният интерфейс за командния ред на пакета smartmontools, предназначен за заявки, тестване и интерпретиране на данни от S.M.A.R.T. (Self-Monitoring, Analysis, and Reporting Technology), вградени във фърмуера на HDD, SSD и NVMe устройства. Той комуникира директно с фърмуера на устройството чрез ATA, SCSI или NVMe интерфейси, за да извлича необработена диагностична телеметрия, която операционната система сама по себе си не излага чрез стандартни I/O пътища.

За всеки Linux администратор, управляващ физическо или виртуално хранилище — независимо дали на bare-metal сървър, Dedicated Server или локално свързан дисков масив — smartctl е единственият най-надежден инструмент за откриване на предстоящ отказ на устройство, преди да причини невъзстановима загуба на данни.

Какво е S.M.A.R.T. и защо е важно

S.M.A.R.T. е система за мониторинг, вградена практически във всяко потребителско и корпоративно устройство за съхранение, произведено след 1996 г. Тя работи на ниво фърмуер, непрекъснато проследявайки десетки вътрешни параметри: честота на грешки при четене/запис, индикатори за механично натоварване, нива на износване на NAND, брой преразпределени сектори и термични показания.

Критичното разграничение, което повечето ръководства пропускат: данните от S.M.A.R.T. са предиктивни, а не реактивни. Едно устройство може да премине проверка на файловата система и да обслужва I/O нормално, докато едновременно натрупва преразпределени сектори с темп, който статистически предсказва отказ в рамките на седмици. smartctl разкрива това скрито деградирало състояние.

S.M.A.R.T. работи в три фамилии интерфейси за съхранение:

• ATA/SATA — оригиналната спецификация на S.M.A.R.T., най-богата на атрибути
• SCSI/SAS — използва различен модел на атрибути (Informational Exceptions log pages)
• NVMe — излага здравни данни чрез NVMe Health Information Log (Log Page 0x02), с метрики като налично резервно пространство, процент на използване и небезопасни изключвания

Инсталиране на smartmontools на Linux

Пакетът smartmontools е наличен в официалните хранилища на всяка основна Linux дистрибуция. Инсталирайте версията, подходяща за вашата среда:

Debian / Ubuntu:

“`bash

sudo apt-get update && sudo apt-get install smartmontools

“`

CentOS / RHEL 7:

“`bash

sudo yum install smartmontools

“`

CentOS Stream / RHEL 8+ / AlmaLinux / Rocky Linux:

“`bash

sudo dnf install smartmontools

“`

Fedora:

“`bash

sudo dnf install smartmontools

“`

Arch Linux:

“`bash

sudo pacman -S smartmontools

“`

openSUSE:

“`bash

sudo zypper install smartmontools

“`

След инсталацията проверете версията и потвърдете, че поддръжката на NVMe е компилирана:

“`bash

smartctl –version

“`

Потърсете `NVMe` в списъка с поддържани типове устройства. Версии преди 6.6 имат непълна поддръжка на NVMe — на съвременни сървъри с NVMe SSD се уверете, че използвате smartmontools 7.x или по-нова версия.

Идентифициране на вашите устройства за съхранение

Преди да изпълните каквато и да е команда на smartctl, идентифицирайте правилния възел на устройството. Объркването на идентификаторите на устройства в система с множество дискове е честа и скъпоструваща грешка.

“`bash

lsblk -d -o NAME,SIZE,MODEL,TRAN

“`

Това извежда имена на устройства заедно с типа на транспорта (sata, nvme, usb), което директно указва кои флагове на smartctl ще са ви необходими. За NVMe устройства, възелът ще се появи като `/dev/nvme0`, `/dev/nvme1` и т.н. — не `/dev/sdX`.

За хардуерни RAID контролери (LSI MegaRAID, Adaptec, HP Smart Array), устройствата са скрити зад контролера и изискват изрични флагове за pass-through, разгледани в разширения раздел по-долу.

Основни команди на smartctl

Преглед на информацията за идентификация на устройството

“`bash

sudo smartctl -i /dev/sda

“`

Това заявява страницата IDENTIFY DATA на устройството и връща номера на модела, серийния номер, ревизията на фърмуера, капацитета, размера на сектора (512-байтов логически срещу 4096-байтов физически — важно за подравняване) и флаговете за възможности на S.M.A.R.T. За NVMe устройства:

“`bash

sudo smartctl -i /dev/nvme0

“`

Извършване на пълна здравна оценка

“`bash

sudo smartctl -H /dev/sda

“`

Връща еднолинейна присъда: `PASSED` или `FAILED`. Резултат `FAILED` означава, че собственият фърмуер на устройството е определил, че един или повече критични прагове са надхвърлени. Устройство, съобщаващо FAILED, трябва да се третира като отказало — не чакайте за допълнително потвърждение.

Въпреки това, резултат `PASSED` не означава, че устройството е здраво. Означава само, че никой праг не е официално надхвърлен. Ето защо анализът на необработените атрибути е от съществено значение.

Показване на всички атрибути на S.M.A.R.T.

“`bash

sudo smartctl -A /dev/sda

“`

Това е командата с най-голяма информационна плътност при рутинна употреба. Таблицата с резултати съдържа няколко колони, които изискват прецизна интерпретация:

RAW_VALUE е това, което трябва да анализирате основно. Нормализираната система VALUE/WORST/THRESH е полезна за автоматично откриване на прагове, но може да бъде подвеждаща — някои производители използват нестандартни криви на нормализация.

Изчерпателен изход: Комбиниране на флагове

За пълна картина с една команда, комбинирайте флаговете за информация, здраве и атрибути:

“`bash

sudo smartctl -a /dev/sda

“`

Флагът с малки букви `-a` е еквивалентен на `-H -i -c -A -l error -l selftest`. Това е стандартната команда за изпълнение при диагностициране на непознато устройство.

За още по-подробен изход, включващ всички log pages:

“`bash

sudo smartctl -x /dev/sda

“`

Критични атрибути на S.M.A.R.T. и как да ги интерпретирате

Не всички атрибути на S.M.A.R.T. имат еднакво диагностично значение. Следните са атрибутите, които опитните инженери по съхранение третират като основни индикатори за отказ:

Индикатори за отказ с висок приоритет

Reallocated_Sector_Ct (ID 5)

Броят на секторите, които устройството е преразпределило в резервна зона поради грешки при четене/запис/проверка. Всяка ненулева стойност на устройство под две години изисква незабавно внимание. Постоянно нарастващ брой — дори от 1 до 5 за месец — е силен предиктор за предстоящ отказ. При корпоративни устройства, малък брой може да е приемлив в зависимост от спецификацията на производителя.

Current_Pending_Sector (ID 197)

Сектори, маркирани като нестабилни и чакащи преразпределение. Тези сектори са произвели грешки по време на четене, но все още не са успешно преразпределени. Ненулева стойност тук означава, че устройството активно се затруднява да чете данни. Ако даден чакащ сектор впоследствие бъде успешно записан, той може да бъде преразпределен или изчистен — но основният носител е под съмнение.

Uncorrectable_Sector_Count (ID 198) / Offline_Uncorrectable

Сектори, които не могат да бъдат коригирани от ECC и не могат да бъдат преразпределени. Това е най-сериозният атрибут. Ненулева стойност тук означава, че данните вече са загубени от тези сектори. Незабавното архивиране и подмяна на устройството е единственият подходящ отговор.

Reported_Uncorrect (ID 187)

При съвременните устройства, това брои грешки, които вътрешният ECC на устройството не е могъл да коригира. Високите стойности указват сериозна деградация на носителя.

Spin_Retry_Count (ID 10)

При HDD, повтарящи се неуспехи при завъртане на плочите до работна скорост. Указва механично натоварване на шпинделния мотор или лагерите. Всяка ненулева стойност при устройство под интензивна употреба е тревожен сигнал.

Command_Timeout (ID 188)

Броят на командите, прекъснати поради изтичане на времето. Повишените стойности често указват проблеми с интерфейса (кабел, контролер или захранване), а не отказ на носителя — но могат също да предшестват пълен отказ на устройството.

Атрибути за вторичен мониторинг

Raw_Read_Error_Rate (ID 1)

Често погрешно интерпретиран: при устройства Seagate, този атрибут има много висока необработена стойност по дизайн, тъй като представлява съотношение, кодирано в 48-битово поле. Необработена стойност от няколко милиона при устройство Seagate е нормална. При Western Digital и други производители, необработената стойност трябва да е близо до нула. Винаги правете кръстосана справка с документацията на производителя, преди да алармирате за този атрибут.

Power_On_Hours (ID 9)

Общи оперативни часове. Потребителските HDD обикновено са оценени за 20 000–25 000 часа (приблизително 2–3 години непрекъсната работа). Корпоративните устройства са оценени за 55 000+ часа. Използвайте това за контекстуализиране на стойностите на другите атрибути.

Temperature_Celsius (ID 194)

Текущата температура на устройството. Оптималният работен диапазон за повечето HDD е 25–45°C. Продължителни температури над 55°C ускоряват износването на лагерите и деградацията на магнитния носител. При SSD, термичната толерантност е като цяло по-висока, но продължителни температури над 70°C ще ускорят износването на NAND. На сървъри без адекватен въздушен поток — честа проблема при плътни rack инсталации — термичното ограничаване може да се маскира като I/O латентност, преди температурният атрибут да надхвърли какъвто и да е официален праг.

Wear_Leveling_Count (ID 177) / Media_Wearout_Indicator (ID 233)

Атрибути специфични за SSD, проследяващи консумацията на издръжливостта на NAND. Когато нормализираната стойност VALUE се доближи до стойността THRESH, SSD наближава своята оценена издръжливост при запис. Планирайте подмяна проактивно.

Power_Cycle_Count (ID 12)

Честото включване/изключване причинява механично натоварване на HDD (паркиране/разпаркиране на главите, натоварване на шпинделния мотор) и в по-малка степен електрическо натоварване на SSD. Необичайно високи стойности спрямо Power_On_Hours могат да указват нестабилна захранваща среда.

Изпълнение на диагностични самотестове

Самотестовете на S.M.A.R.T. се изпълняват от собствения фърмуер на устройството, а не от операционната система. Устройството продължава да обслужва I/O по време на тестването (с незначително влияние върху производителността), което прави тези тестове безопасни за изпълнение на производствени системи.

Кратък самотест

“`bash

sudo smartctl -t short /dev/sda

“`

Продължителност: обикновено 1–5 минути. Тества електрическите и механичните компоненти и малък процент от повърхността на диска. Полезен за бърза проверка. Вижте резултатите след завършване:

“`bash

sudo smartctl -l selftest /dev/sda

“`

Дълъг самотест (разширен тест)

“`bash

sudo smartctl -t long /dev/sda

“`

Продължителност: пропорционална на капацитета на устройството — очаквайте 1 час на терабайт при типичен 7200 RPM HDD и 20–60 минути при повечето SSD. Извършва пълно сканиране на повърхността на всеки сектор. Това е окончателният тест за откриване на лоши сектори по цялата повърхност на носителя.

Наблюдавайте напредъка без да чакате завършване:

“`bash

sudo smartctl -c /dev/sda

“`

Изходът включва процент на завършеност и прогнозно време за приключване.

Conveyance самотест

“`bash

sudo smartctl -t conveyance /dev/sda

“`

Наличен при повечето ATA устройства. Предназначен за откриване на повреди, настъпили по време на транспортиране или физическо боравене. Проверява за проблеми, причинени от механичен удар. Продължителността е обикновено 5 минути. Този тест е недостатъчно използван — той е особено ценен при въвеждане в експлоатация на нов хардуер или след физическо преместване на сървър.

Selective самотест

“`bash

sudo smartctl -t select,0-1000000 /dev/sda

“`

Позволява тестване на конкретен LBA диапазон, а не на цялото устройство. Безценен, когато проверките на файловата система са маркирали грешки в конкретна област и трябва да потвърдите дали основният носител е отговорен.

Мониторинг на здравето специфичен за NVMe

NVMe устройствата използват фундаментално различен модел на атрибути. Основната здравна команда:

“`bash

sudo smartctl -a /dev/nvme0

“`

Ключови полета специфични за NVMe за наблюдение:

• Available Spare: Процент на оставащите резервни NAND блокове. Под 10% изисква планиране на подмяна.
• Available Spare Threshold: Дефинираният от производителя праг, под който устройството може да съобщи за намалена надеждност.
• Percentage Used: Прогнозен процент на консумираната оценена издръжливост при запис. При 100%, устройството е достигнало своя оценен TBW (Terabytes Written) — може да продължи да функционира, но гаранциите за надеждност вече не се прилагат.
• Data Units Read / Written: Кумулативен I/O в единици от 512 000 байта. Полезен за изчисляване на действителното натоварване спрямо оценения TBW.
• Media and Data Integrity Errors: Невъзстановени грешки на носителя или грешки в целостта на данните, открити от NVMe контролера. Всяка ненулева стойност е сериозна.
• Number of Error Information Log Entries: Брой записи в журнала на грешките. Бързо нарастващ брой указва постоянни проблеми.
• Power State: Текущото NVMe захранващо състояние — релевантно за натоварвания, чувствителни към латентност, при които устройството може да е в дълбоко енергоспестяващо състояние.

Хардуерен RAID и pass-through достъп

Когато устройствата са свързани чрез хардуерен RAID контролер, операционната система вижда виртуалния диск на контролера, а не физическите устройства. smartctl изисква изричен pass-through за директен достъп до фърмуера на устройството.

LSI MegaRAID:

“`bash

sudo smartctl -a /dev/sda -d megaraid,0

sudo smartctl -a /dev/sda -d megaraid,1

“`

HP Smart Array (hpsa драйвер):

“`bash

sudo smartctl -a /dev/sda -d cciss,0

“`

3ware RAID:

“`bash

sudo smartctl -a /dev/twa0 -d 3ware,0

“`

Ако не сте сигурни кой тип pass-through да използвате, smartctl може да опита автоматично разпознаване:

“`bash

sudo smartctl –scan

“`

Това сканира за всички разпознаваеми устройства за съхранение и извежда препоръчания път на устройството и флага за тип за всяко от тях.

Активиране и деактивиране на S.M.A.R.T.

S.M.A.R.T. е активиран по подразбиране на практически всички съвременни устройства. В редки случаи — обикновено по-стари устройства или определени виртуализирани среди — може да е деактивиран:

“`bash

sudo smartctl -s on /dev/sda

“`

За деактивиране (не се препоръчва освен за конкретни сценарии на тестване):

“`bash

sudo smartctl -s off /dev/sda

“`

Забележка: Във виртуализирани среди като KVM или VMware, pass-through на S.M.A.R.T. към гост VM зависи от конфигурацията на хипервайзора. В среда за VPS Hosting, хипервайзорът обикновено абстрахира физическото устройство и smartctl вътре в госта може да върне ограничени или никакви данни. За пълен достъп до S.M.A.R.T., необходим е мониторинг на ниво физически хост или Dedicated Server.

Автоматизиран мониторинг със smartd

Демонът smartd е компонентът от производствен клас на smartmontools. Той работи на заден план, периодично анкетира устройствата и изпълнява планирани тестове, след което предупреждава администраторите, когато прагове са надхвърлени или тестовете са неуспешни.

Конфигуриране на /etc/smartd.conf

Конфигурацията по подразбиране наблюдава всички открити устройства с основни настройки. Конфигурация, закалена за производство, изглежда така:

“`

Monitor all ATA/SCSI/NVMe drives with full attribute checking

Run short test every day at 02:00, long test every Saturday at 03:00

Email alert on any failure or attribute change

DEVICESCAN -a -o on -S on

-s (S/../.././02|L/../../6/03)

-m admin@yourdomain.com

-M exec /usr/share/smartmontools/smartd-runner

“`

Обяснение на ключовите директиви:

Активиране и стартиране на smartd

“`bash

sudo systemctl enable smartd

sudo systemctl start smartd

sudo systemctl status smartd

“`

Проверете дали демонът активно наблюдава:

“`bash

sudo journalctl -u smartd -f

“`

Конфигуриране на имейл предупреждения

За да функционират имейл предупрежденията на smartd, системата изисква работещ MTA (mail transfer agent). При минимални сървърни инсталации, инсталирайте и конфигурирайте `postfix` или `msmtp` за relay. Ако използвате специализирана пощенска инфраструктура, помислете за съчетаване на предупрежденията от smartd с правилно конфигурирана услуга за Email Hosting, за да гарантирате, че доставката на предупрежденията не е блокирана от спам филтри.

Сравнение на атрибути на S.M.A.R.T.: HDD срещу SSD срещу NVMe

Практически работен процес: Диагностициране на съмнително устройство

Когато дадено устройство проявява симптоми — I/O грешки в `dmesg`, повреда на файловата система, необичайна латентност — следвайте тази диагностична последователност:

Стъпка 1: Потвърдете наличността на S.M.A.R.T.

“`bash

sudo smartctl -i /dev/sda | grep -i "SMART support"

“`

Стъпка 2: Проверете общата здравна присъда

“`bash

sudo smartctl -H /dev/sda

“`

Стъпка 3: Прегледайте журнала на грешките

“`bash

sudo smartctl -l error /dev/sda

“`

Журналът на грешките записва последните 5 ATA грешки с времеви марки и LBA адреси. Кръстосано справете LBA адресите с картите на блоковете на файловата система, използвайки `debugfs` или `xfs_db`, за да определите дали грешките засягат критични структури на файловата система.

Стъпка 4: Анализирайте критичните атрибути

“`bash

sudo smartctl -A /dev/sda | grep -E "Reallocated|Pending|Uncorrectable|Command_Timeout"

“`

Стъпка 5: Изпълнете кратък тест за незабавно потвърждение

“`bash

sudo smartctl -t short /dev/sda

sleep 120

sudo smartctl -l selftest /dev/sda

“`

Стъпка 6: Ако краткият тест премине и симптомите продължават, изпълнете дълъг тест по време на прозорец за поддръжка

“`bash

sudo smartctl -t long /dev/sda

“`

Стъпка 7: Прегледайте журнала на самотестовете за LBA адреси на грешки

“`bash

sudo smartctl -l selftest /dev/sda

“`

Неуспешните тестове отчитат LBA на първата открита грешка. Това точно определя местоположението на повредата на носителя.

Чести грешки и гранични случаи

Устройства, свързани чрез USB: smartctl често не може да комуникира с устройства, свързани чрез USB-to-SATA адаптери, тъй като USB bridge чипът не препраща ATA команди. Използвайте флага `-d sat` или `-d usb`, или посочете типа на моста изрично (напр. `-d usb,0x0bc2,0x2312`). Флагът `–scan` ще се опита да идентифицира правилния тип автоматично.

Виртуализирани среди: Вътре в KVM или VMware гост, `/dev/sda` е виртуален диск. smartctl може да върне `Device does not support SMART` или фабрикувани данни, предадени от хипервайзора. Не разчитайте на изхода на smartctl вътре в госта за оценка на здравето на физическото устройство при инфраструктура за споделен хостинг.

Фалшиви положителни резултати при Raw_Read_Error_Rate: Както беше отбелязано по-горе, кодирането на този атрибут от Seagate причинява тревожни необработени стойности, които са напълно нормални. Винаги проверявайте спрямо документацията на атрибутите на производителя, преди да действате въз основа на тази стойност.

Устройства зад софтуерен RAID (mdadm): smartctl достъпва компонентните устройства директно (`/dev/sda`, `/dev/sdb`), а не RAID устройството (`/dev/md0`). Наблюдавайте всяко членово устройство поотделно.

NVMe пространство от имена срещу контролер: Използвайте `/dev/nvme0` (контролер) за здравни данни, а не `/dev/nvme0n1` (пространство от имена/блоково устройство). Някои версии на smartctl приемат и двете, но възелът на контролера е авторитетен за достъп до журнала на здравето.

Устройства, които лъжат: Някои потребителски SSD, особено устройства с QLC NAND от по-ниско ниво, са документирани да отчитат здравословни атрибути на S.M.A.R.T. до пълен и внезапен отказ. S.M.A.R.T. е силен индикатор, но не е гаранция — той не замества редовните архиви.

Внедряване на smartmontools в сървърни среди

За администратори, управляващи множество физически сървъри — като тези, изпълняващи натоварвания на Dedicated Servers — централизирането на мониторинга на S.M.A.R.T. е от съществено значение. Помислете за следната архитектура:

• Prometheus + node_exporter: `node_exporter` включва скрипт за колектор на текстови файлове `smartmon`, който експортира атрибути на S.M.A.R.T. като Prometheus метрики. Това позволява предупреждения чрез Alertmanager и визуализация в Grafana табла.
• Nagios / Icinga2: Плъгинът `check_smart` осигурява интеграция на мониторинга на S.M.A.R.T. за традиционни стекове за мониторинг.
• Персонализирани скриптове за smartd: Директивата `-M exec` в smartd.conf може да задейства всякакъв скрипт при предупреждение — полезно за интегриране с PagerDuty, Slack webhooks или персонализирани системи за тикети.
• Агрегиране на журнали: Конфигурирайте smartd да записва в syslog, след което препращайте към централизиран агрегатор на журнали (ELK стек, Loki) за исторически анализ на тенденциите в целия флот.

За среди за уеб хостинг, използващи контролни панели, внедряванията на VPS с cPanel се възползват от мониторинга на S.M.A.R.T. на ниво хост, конфигуриран от доставчика на инфраструктурата, тъй като cPanel сам по себе си не излага данни за здравето на устройствата по естествен начин.

Контролен списък с ключови изводи

Използвайте това като справка преди внедряване и за текущи оперативни дейности:

• Инсталирайте smartmontools 7.x или по-нова версия, за да осигурите пълна поддръжка на NVMe и съвременни SSD
• Изпълнете `smartctl –scan` на нов хардуер, за да идентифицирате всички устройства и техните необходими флагове за интерфейс
• Проверете първо здравната присъда `-H` — резултат `FAILED` изисква незабавни действия независимо от другите атрибути
• Третирайте всяка ненулева стойност на Reallocated_Sector_Ct, Current_Pending_Sector или Uncorrectable_Sector_Count като сигнал за отказ — не чакайте броят да нараства
• Не разчитайте единствено на Raw_Read_Error_Rate — валидирайте спрямо документацията на производителя, преди да алармирате
• Планирайте автоматизирани дълги тестове седмично чрез smartd на всички производствени устройства; кратки тестове ежедневно
• Конфигурирайте имейл предупреждения на smartd и проверете доставката, преди да разчитате на тях
• За хардуерен RAID, винаги използвайте подходящия флаг за pass-through — наблюдението на виртуалния диск не е еквивалентно на наблюдението на физическите устройства
• Във виртуализирани среди, извършвайте мониторинга на S.M.A.R.T. на ниво хипервайзор/хост, а не вътре в гост VM
• Съчетайте мониторинга на S.M.A.R.T. със стратегия за архивиране — S.M.A.R.T. предсказва отказ, но не предотвратява загубата на данни
• За NVMe устройства, наблюдавайте Available Spare и Percentage Used в допълнение към броя на грешките
• На сървъри с множество устройства, интегрирайте smartd с централизирана платформа за предупреждения, вместо да разчитате на локална имейл доставка

Често задавани въпроси

Работи ли smartctl вътре в VPS или облачен инстанс?

В повечето VPS среди, хипервайзорът представя виртуално блоково устройство на госта. smartctl вътре в госта ще върне или никакви данни, или данни, синтезирани от хипервайзора, които не отразяват действителното здраве на физическото устройство. Смисленият мониторинг на S.M.A.R.T. изисква достъп до физическия хост. За пълна видимост на ниво устройство, Dedicated Server е подходящото решение.

Каква е разликата между `smartctl -a` и `smartctl -x`?

Флагът `-a` извежда стандартния набор от данни на S.M.A.R.T.: информация за устройството, здравна присъда, флагове за възможности, всички атрибути, журнал на грешките и журнал на самотестовете. Флагът `-x` извежда всичко, което предоставя `-a`, плюс допълнителни log pages, включително журнала на selective самотестовете, журнала на статистиките на устройството, журнала на чакащите дефекти и статистиките на ATA устройството — осигурявайки по-пълна картина на историята на устройството. Използвайте `-x` за задълбочена диагностика; `-a` за рутинни проверки.

Колко дълго отнема дългият самотест и безопасно ли е да се изпълнява на производствено устройство?

Продължителността зависи от капацитета и скоростта на устройството: приблизително 1 час на терабайт за 7200 RPM HDD и 20–60 минути за повечето SSD. Тестът се изпълнява на заден план във фърмуера на устройството, а устройството продължава да обслужва I/O по време на теста. Влиянието върху производителността е обикновено незначително (5–15% намаление на пропускателната способност). Безопасно е да се изпълнява на производствени системи по време на периоди с ниско натоварване, но планирането по време на прозорец за поддръжка се препоръчва за натоварвания, чувствителни към латентност.

Какво означава, когато Current_Pending_Sector е ненулев, но Reallocated_Sector_Ct не се е увеличил?

Устройството е идентифицирало сектори, произвеждащи грешки при четене, но все още не ги е успешно преразпределило. Преразпределянето настъпва, когато устройството може да запише в сектора — или чрез операция за запис, или чрез офлайн сканиране. Ако броят остава статичен, секторите може да са в регион само за четене или устройството може да няма налични резервни сектори за преразпределяне. Ненулев и нарастващ брой на Current_Pending_Sector, при оставащ неизменен Reallocated_Sector_Ct, често указва, че устройството е изчерпало своя пул от резервни сектори — критично условие за отказ.

Може ли smartctl да открие износването на SSD преди отказ на устройството?

Да, за SATA SSD, атрибутите Wear_Leveling_Count (ID 177), Media_Wearout_Indicator (ID 233) и Available_Reservd_Space (ID 232) проследяват консумацията на издръжливостта на NAND. За NVMe SSD, полетата Percentage Used и Available Spare в NVMe Health Information Log служат за същата цел. Когато Available Spare падне под своя праг или Percentage Used достигне 100%, устройството е консумирало своята оценена издръжливост при запис. За разлика от внезапните механични откази, деградацията от износване на SSD е постепенна и силно предсказуема — което го прави един от най-силните случаи на употреба за проактивен мониторинг на S.M.A.R.T.