Лимит записи SSD-дисков на примере Asus Eeepc

Позвольте мне предоставить некоторые цифры, основанные на точных измерениях и обоснованных предположениях.

Во-первых, вначале я протестировал скорость записи своего Eee PC с использованием программы DiskBench методом копирования и создания файлов на приводе SSD. В зависимости от типа файла, который я записывал, средняя скорость варьировалась от 1.1 МБ/с до 3 МБ/с.

Во-вторых, чтобы оценить степень распределения записи флеш-памяти SSD, нужно быть знакомым с архитектурой Eee PC. (Имеется в виду прием wearing level, который используется в контроллерах флеш-памяти, для предотвращения многократной записи подряд в одну и ту же ячейку памяти, а запись распределяется равномерно). Мои расчеты основаны на двух случаях: когда распределение записи происходит идеально равномерно (что маловероятно) и когда системе удается достичь эффективности 50% для равномерного распределения записи (это чуть хуже, чем индустриальный стандарт).

В-третьих, определение реального времени записи при использовании ноутбука в жизни представляется довольно сложной задачей. Например, если вы оставляете компьютер включенным 100% времени, а запись осуществляется 1% от этого времени, то выходит, что данные на диск пишутся непрерывно 15 минут в день. Если вы считаете, что этот процент выше, то вы можете посмотреть соответствующие данные в приведенной таблице, которые линейно зависят от этого процента.

Предположения:

1) Реальная интенсивность износа составляет некий процент от расчетной интенсивности износа.
2) Скорость записи находится в пределах, указанных в таблице.
3) Количество байт и количество секторов (куда, собственно, и осуществляется запись) прямо пропорциональны.
4) 1 000 000 байт = 1 МБ - это приемлемое округление для рассматриваемых временных рамок.
5) Eee PC может осуществить от 100 000 до 200 000 циклов записи на сектор до того, как он будет поврежден.

Для использования таблицы выберите под-таблицу с предполагаемой интенсивностью записи и максимальным количеством циклов записи (серые строчки). Перейдите на строчку в этой под-таблице, примерно соответствующей скорости записи в МБ/с, которую вы, возможно, измерили. И посмотрите на последнюю ячейку в этой строчке, чтобы увидеть через сколько лет SSD-диск выйдет из строя (или, возможно, станет ненадежным), но при 100% непрерывной записи на диск все это время.

Таким образом, можно примерно оценить время жизни SSD-диска Eee PC в годах. Пары строк, подсвеченных желтым, представляют самый распространенный диапазон, который я получал в своих тестах на запись. Я расширил таблицу строчками ниже вплоть до скорости 10 МБ/с, чтобы увидеть самое короткое возможное время жизни.

Например: Обычный пользователь Eee PC использует ноутбук 6 часов в день, на SSD-диск которого осуществляется запись 10% от этого времени, т.е. 36 минут в день. Следовательно, время жизни его диска будет составлять примерно 25 лет в самом худшем случае (последняя строчка в таблице):

231 дн. непрер. исп-ия * 24 часов в дне * 60 минут в часе / 36 минут в день = 9240 дней использования на 10%; 9240 дн. / 365 дн. в г. = ~25 лет.

Другими словами, многие опасения насчет раннего выхода из строя SSD-диска не являются оправданными.

Однако на форумах неоднократно проскакивают крики о помощи. Смерть SSD не такое уж редкое явление. Я сам недавно столкнулся с подобным. Сначала появились тормоза, несколько раз после перезагрузки запускался fsck и находил повреждение данных. Но после одной из них комп отказался загружаться вообще. Я запустил проверку диска, после чего получил девственно чистый домашний каталог. Сначала подумалось, что fsck стёр данные, но как велико же было разочарование, когда я не обнаружил 16GB SSD в списке дисков! Далее пошли потуги с изучением логов, форматированием, разметкой и так по кругу. Всё безуспешно … SSD умер. Почитав форум на данном уважаемом сайте и попробовав переписать биос (зря портаченное время) я начал искать продавцов SSD. Наутро меня осенило, и я решил разбить 16ГБ на два раздела первый не примонтировался, зато второй О ЧУДО!!! Ура!!! Так… И я опять полез в логи, где почерпнул, что ошибки всегда возникают на блоках с определёнными номерами в начале диска. В конце концов, подобрав номер стартового блока мне удалось получить 15.8 GB работоспособного SSD.

Выводы:

Вышли из строя часть блоков одного из чипов (MLC NAND) SSD. Вопрос: почему? После изучения кода EXT3 (журналируемая файловая система, базируется на EXT2) стало ясно, что флешку запилил журнал! Такая же судьба постигла несколько EEEPC с виндами (NTFS) в одной компании. Не даром разработчики YAFFS (Yet another file system) никогда не пишут в один и тот же сектор, пока не пройдут весь NAND по кругу. Моё мнение такое: журнал - есть смерть для SSD.

Как сохранить деньги:

если позволяет квалификация - попробуйте локализовать убитые сектора. Или методом подбора - двигая стартовый блок в программе fdisk.

Как их не потерять снова:

Не используйте для SSD журналируемые файловые системы. Никогда! Для виндов подойдёт FAT32. Для Linux-EXT2. Забудте про NTFS EXT3 и Reiser

Автор в своих расчётах основывается на том, что приблизительное количество циклов перезаписи чипов MLC NAND 100-200 тысяч раз. Это, по меньшей мере, неточно. Такое количество циклов перезаписи присуще чипам SLC NAND, которые ощутимо дороже, и потому не устанавливались в Eee PC. А если быть точным, то производители гарантируют количество циклов перезаписи ячеек памяти для SLC NAND до 100 тысяч раз. В то время, как для MLC чипов производители гарантируют до 10 тысяч циклов. То есть, полученная цифра в 25 лет будет в 10 раз меньше - 2,5 года. Кроме того, опыт автора с убитыми журналом секторами говорит о том, что эти ячейки вышли из строя достаточно быстро, никак не за 100 тыс. раз записи.

Как известно, NTFS - журналируемая файловая система, что выдается Microsoft за ее достоинство, хотя это скорее недостаток. Журнал не только занимает место, не только отнимает драгоценное время, замедляя интенсивные дисковые операции, но и в некоторых случаях приводит к полному краху - в коде, связанном с поддержкой журнала, за всю историю существования NTFS, было обнаружено, по меньшей мере, три ошибки, ушедших в релиз и приводящих к BSOD при попытке монтирования NTFS-тома, что делало данные практически недоступными. «Практически», потому что знающие люди использовали загрузочные диски с Linux, поддерживающие NTFS на очень низком уровне (то есть без журналирования), перегоняя все ценные файлы по сети на соседний компьютер или уничтожая журнал в дисковых редакторах/системных утилитах.

Итак, с теорией все понятно, теперь практические действия:

1) Пуск ⇒ выполнить ⇒ cmd ⇒ ОК
2) Отключаем журналирование, например для диска Z.

Вводим в командной строке:

fsutil usn deletejournal /D Z:

Все, журналирование для диска Z отключено.

Если возникнет необходимость включить журналирование опять, то сделать это очень просто:
1) Пуск ⇒ выполнить ⇒ cmd ⇒ ОК
2) Вводим в командной строке:

fsutil usn createjournal m=1000 a=100 Z:

Все, журналирование для диска Z включено.

Информация взята с сайта eee-pc.ru