Если вы активно работаете с SSD, особенно в Linux-системах, могли заметить странное поведение: значение Power_On_Hours в SMART-атрибутах увеличивается гораздо медленнее реального времени работы диска. Например, после двух недель использования диск показывает всего 7 часов, а замена ведёт себя аналогично. Всё это вызывает вопросы: не брак ли это, не ошибка ли прошивки, и главное – стоит ли волноваться?
Давайте разбираться. Современные SSD – это не просто «флешки в корпусе». Их контроллеры управляют множеством процессов: износ ячеек, кеширование, распределение данных, энергопотребление. И если для HDD операционная система напрямую влияла на многие параметры, то SSD часто принимают решения самостоятельно. Это приводит к неочевидным ситуациям, включая подсчёт времени работы.
Почему Power_On_Hours может «отставать»?
Особенности управления питанием SSD: В отличие от HDD, SSD не требует постоянной механической активности. Контроллер диска может переводить его в режимы низкого энергопотребления даже во время «простоя» системы. Например:
- APM (Advanced Power Management): уровень 254 (максимальная производительность) не отключает полностью фоновые оптимизации.
- DIPM (Device Initiated Power Management): технология, при которой диск сам решает, когда снизить энергопотребление, независимо от настроек ОС.
Если диск не получает команды чтения/записи (например, не смонтирован или не используется), он может «засыпать» на короткие периоды, что влияет на подсчёт Power_On_Hours. В некоторых моделях этот атрибут учитывает только активное состояние, игнорируя время в режиме ожидания.
Пример из практики: SanDisk SSD PLUS 1000GB после 48 часов работы в Linux без монтирования показывал 0 часов. Причина – отсутствие операций ввода-вывода, хотя диск был физически подключён.
Как проверить состояние SSD
Инструменты для диагностики: Для анализа используйте утилиты, которые читают SMART-данные:
1. В Linux:
sudo smartctl -x /dev/sdX # Полный отчёт с расширенной информацией
sudo hdparm -I /dev/sdX # Проверка режимов питания (APM)Обратите внимание на параметры:
– Power_On_Hours (ID 9) – часы работы;
– Power_Cycle_Count (ID 12) – количество включений;
– Drive State из вывода hdparm -C – активен ли диск сейчас.
2. В Windows:
– CrystalDiskInfo;
– SanDisk Dashboard (для фирменных дисков).
Если все тесты (включая Extended Self-Test через smartctl -t long) проходят успешно, а остальные атрибуты (Reallocated_Sector_Ct, Temperature_Celsius) в норме – проблема, скорее всего, в логике подсчёта часов, а не в дефекте.
Когда стоит беспокоиться? Красные флаги и ложные сигналы: Медленный рост Power_On_Hours сам по себе не указывает на неисправность. Тревожиться нужно, если:
– Появились ошибки в разделах SMART Extended Comprehensive Error Log;
– Растёт значение Reallocated_Sector_Ct (переназначенные секторы);
– Частые перезагрузки или внезапные отключения диска.
# Пример нормального вывода smartctl для сравнения:
ID# ATTRIBUTE_NAME VALUE WORST THRESH RAW_VALUE
5 Reallocated_Sector_Ct 100 100 010 0
9 Power_On_Hours 100 100 000 0
194 Temperature_Celsius 100 100 014 24Для дисков SanDisk с firmware 42077100 и аналогичных характерно «консервативное» обновление атрибутов. Это подтверждается и на форумах: пользователи AnandTech и Solidigm отмечают аналогичное поведение без последствий для надёжности.
Можно ли «исправить» подсчёт часов?
К сожалению, повлиять на логику работы SMART-атрибутов почти невозможно – она зашита в микропрограмму контроллера. Однако можно:
1. Обновить прошивку через официальные утилиты (например, SanDisk SSD Dashboard).
2. Отключить DIPM в настройках BIOS/UEFI (если опция доступна).
3. Создать нагрузку на диск – смонтировать раздел, записать тестовые файлы.
Внимание: изменение параметров APM через hdparm (например, sudo hdparm -B 255 /dev/sdX) может увеличить энергопотребление, но не гарантирует коррекции Power_On_Hours.
Итог: стоит ли игнорировать аномалии? Если диск проходит стресс-тесты, не перегревается и не теряет данные – скорее всего, это особенность модели. Производители оптимизируют firmware под свои задачи, и «странности» в отображении служебной информации – не редкость.
Однако смело рекомендую:
– Регулярно проверяйте SMART-данные (хотя бы раз в месяц);
– Делайте резервные копии критически важных данных;
– При подозрении на деградацию NAND-памяти (например, резкий рост Total_Bad_Block) – обращайтесь в сервис.
И помните: SSD – чёрный ящик. Мы видим только то, что разработчики сочли нужным показать. Главное – не цифры в мониторинге, а реальная производительность и сохранность файлов.