Pull to refresh

Как я угробил SSD за два месяца

Reading time 4 min
Views 418K
Эпиграф
«Никогда не доверяй компьютеру, который не можешь выбросить из окна»
Стив Возняк

Два месяца назад поставил себе в ноутбук SSD диск. Работал он великолепно, но на прошлой неделе он внезапно умер из-за истощения ячеек (как я полагаю). Эта статья посвящена тому, как это случилось, и тому, что я делал неправильно.

Описание окружения

  • Пользователь: Веб-разработчик. То есть в ходу такие вещи как: виртуалки, eclipse, частые обновления репозиториев.
  • ОС: Gentoo. То есть часто «пересобирается мир».
  • ФС: ext4. То есть пишется журнал.


Итак, история начинается в апреле, когда, наконец, у меня дошли руки, чтобы скопировать разделы на 64Гб SSD веник, купленный ещё в сентябре. Намеренно не сообщаю производителя и модель, ибо пока я ещё не сильно разобрался что случилось, да это и не имеет большого значения.

Прирост производительности был конечно колоссальным: всё стало грузиться раза в два быстрее; но, что самое главное, исчез такой паразитный параметр как время доступа. В результате чего можно: в фоновом режиме «пересобирать мир», запускать три-четыре приложения, активно взаимодействующих с диском; всё это практически не отражается на работе. Никакой апгрейд процессора такого не даст.

Что я сделал, чтобы он работал дольше


Конечно же, я изучил многочисленные публикации, о том как беречь SSD-диски. И вот что я сделал:
  • Поставил noatime для разделов, чтобы при обращению к файлу не обновлялась запись о времени последнего доступа.
  • Увеличил оперативку до максимума и отключил своп.

Больше я ничего не делал, так как считал, что компьютер должен служить пользователю, а не наоборот, и излишние пляски с бубном — неправильно.

S.M.A.R.T.


За три дня до падения я озаботился вопросом: а как узнать насколько мне хватит счастья? Я попробовал утилиту smartmontools, но она выводила неверную информацию. Пришлось скачать Datasheet и написать патч для них.
Написав патч, я нарыл один интересный параметр: среднее_количество_стираний/максимальное_количество_стираний = 35000/45000. Но прочитав, что MLC ячейки выдерживают только 10000 циклов, я решил, что эти параметры значат не совсем то, что я думаю, и забил на них.

Хроника падения


Внезапно, во время работы стали происходить необъяснимые вещи, например новые программы не запускались. Ради интереса посмотрел на тот самый S.M.A.R.T. параметр, было уже 37000/50000 (+2000/5000 за три дня). Перезапуститься уже не удалось, не читалась файловая система основного раздела.
Я запустился с компакта и начал проверку. Проверка показала, много битых нодов. В процессе починки утилита начала тестировать на битые сектора и их помечать. Завершилось это всё на следующий день со следующим результатом: 60Гб из 64Гб оказались помеченными как плохими.
На заметку: В SSD винчестерах ячейка считается битой, если туда нельзя записать новую информацию. Чтение из такой ячейки по прежнему будет возможным. По этому эли запустить утилиту badblocks в режиме только чтения, то врядли она что-то найдёт.

Я решил запустить утилиту перепрошивки, ибо она не только перепрошивает, но и переформатирует диск. Утилита начала форматировать, покряхтела и выдала, что превышено разумное допустимое количество битых секторов, а также что есть сбои, поэтому завершить форматирование не возможно.
После этого диск стал определяться как диск с очень странным именем, номером модели и размером в 4Гб. И, в дальнейшем, кроме специализированных, утилит его никто не видит.
Я написал письмо в поддержку производителя. Они порекомендовали мне перепрошить, если не получится, то вернуть продавцу. Гарантии ещё 2 года, так что попробую.
Завершаю данный раздел благодарностями Стиву Возняку, который научил делать меня периодические бекапы.

Что произошло


Честно говоря, я и сам не знаю. Предполагаю следующее: S.M.A.R.T. не врал и ячейки действительно поизносились (это косвенно подтверждает бекап, который я делал за два дня до падения, он при распаковке показал, что даты создания некоторых файлов обнулены). А при проверке на бед сектора контроллер диска просто разрешил помечать все ячейки как битые, в которых превышено допустимое количество циклов записи.

Что нужно делать, если у вас SSD


Windows

Поставить Windows 7 в ней максимально всё оптимизировано для таких дисков. Также поставить много оперативки.

MacOs

Скорее всего оптимизированы только те компьютеры, которые будут сразу продаваться с SSD.

FreeBSD

Поставить 9.0. Почитать советы для линукса, подумать что из них можно сделать.

Linux
  • Поставить ядро 2.6.33, в котором есть оптимизация для таких дисков в виде команды TRIM.
  • Увеличить памяти, чтобы можно было безболезненно отключить своп.
  • Поставить для монтируемых разделов noatime.
  • Использовал файловую систему, сделанную по принципу copy-on-write или нежурналируемую файловую систему (например ext2).
    На текущий момент copy-on-write ФС использовать достаточно сложно. ZFS пока работает только через FUSE. А nilfs и btrfs при монтировании ругаются, что их формат ещё окончательно не финализирован.
  • Включить NOOP IO Scheduler он позволит не выполнять лишних бесполезных действий для SSD.
  • Концептуально верно, но не сильно поможет диску — переброс временных файлов на tmpfs.
  • Для систем интенсивно пишущих в лог нужно хранить в другом месте. В основном это актуально для серверов, для которых без проблем подымается лог сервер.
  • Обзавестись S.M.A.R.T.-утилитами корректно отображающих состояние SSD-диска, чтобы можно было периодически следить за диском.
  • Просто щадить диск. А для гентушников это дополнительно значит не «пересобирать мир».


Вопросы к хабрасообществу

  • Действительно ли за 2 месяца можно убить MLC-ячейки? Я, конечно понимаю, что диск я не жалел, но ничего сверхъестественного я не делал, просто работал как обычно.
  • Гарантийный ли это случай?


UPD: Диск у меня был Transcend TS64GSSD25S-M.
UPD2: В комментах очень хорошие отзывы о SSD Intel и SAMSUNG. Кроме того люди удивляются как можно так быстро убить SSD веник. Поверьте мне, я недоумевал точно также. Тем не менее возможно, что это наспех скроенная SSD серия и её можно быстро убить.
UPD3: В комментах и соседней статье подсказывают, что у меня диск на контролере JMicron, то есть нет кеша и «если нужно было изменить в случайном месте 4кб данных, им приходилось каждый раз стирать целый блок 64-512кб». Могу добавить что мой же диск я видел в продаже в Германии в марте. Так что шанс нарваться на неприятности есть у каждого.

P.S. Ну а пока я поставил старый веник и поглядываю в сторону Hitachi SSD или Intel X25-M.

UPD4: Производитель признал свою проблему с контроллером и вернул деньги.
UPD5: Переехал на Intel X25-M 80G, доволен как слон.
Tags:
Hubs:
If this publication inspired you and you want to support the author, do not hesitate to click on the button
+161
Comments 351
Comments Comments 351

Articles