Здесь будут шапка и навигация. Вернуться на сайт.
Перевод статьи http://wiki.eeeuser.com/ssd_write_limit.
Было много слухов, высказано множество мнений, опасений, предположений насчет времени жизни встроенного SSD-диска ноутбука Eee PC. Пользователь сайта eeeuser.com Kube в этой ветке форума опубликовал замечательный пост, перевод которого и воспроизведен здесь:
Позвольте мне предоставить некоторые цифры, основанные на точных измерениях и обоснованных предположениях.
Во-первых, вначале я протестировал скорость записи своего Eee PC с использованием программы DiskBench методом копирования и создания файлов на приводе SSD. В зависимости от типа файла, который я записывал, средняя скорость варьировалась от 1.1 МБ/с до 3 МБ/с.
Во-вторых, чтобы оценить степень распределения записи флеш-памяти SSD, нужно быть знакомым с архитектурой Eee PC. (Имеется в виду прием wearing level, который используется в контроллерах флеш-памяти, для предотвращения многократной записи подряд в одну и ту же ячейку памяти, а запись распределяется равномерно). Мои расчеты основаны на двух случаях: когда распределение записи происходит идеально равномерно (что маловероятно) и когда системе удается достичь эффективности 50% для равномерного распределения записи (это чуть хуже, чем индустриальный стандарт).
В-третьих, определение реального времени записи при использовании ноутбука в жизни представляется довольно сложной задачей. Например, если вы оставляете компьютер включенным 100% времени, а запись осуществляется 1% от этого времени, то выходит, что данные на диск пишутся непрерывно 15 минут в день. Если вы считаете, что этот процент выше, то вы можете посмотреть соответствующие данные в приведенной таблице, которые линейно зависят от этого процента.
Предположения:
Для использования таблицы выберите под-таблицу с предполагаемой интенсивностью записи и максимальным количеством циклов записи (серые строчки). Перейдите на строчку в этой под-таблице, примерно соответствующей скорости записи в МБ/с, которую вы, возможно, измерили. И посмотрите на последнюю ячейку в этой строчке, чтобы увидеть через сколько лет 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 на очень низком уровне (то есть без журналирования), перегоняя все ценные файлы по сети на соседний компьютер или уничтожая журнал в дисковых редакторах/системных утилитах.
Итак, с теорией все понятно, теперь практические действия:
Вводим в командной строке:
fsutil usn deletejournal /D Z:
Все, журналирование для диска Z отключено.
Пуск ⇒ выполнить ⇒ cmd ⇒ ОК
Вводим в командной строке:
fsutil usn createjournal m=1000 a=100 Z:
Все, журналирование для диска Z включено.