Я приношу глубокие извинения, но всё-таки дополню своё сообщение теми выводами, ради которых это длинное изложение и было написано.
Во-первых, мы можем видеть, что механический подсчет продолжительности жизни SDD основан на принципиально неверных положениях: "Ячейка выдерживает 3000 записей, всего на диске миллион ячеек, если записывать по ячейке в день, то диск прослужит десять миллионов лет. А потом всё равно устареет".
Увы. Против такого соображения действуют как минимум три фактора:
1. Используемые алгоритмы трансляции адресов принципиально не могут обеспечить равномерную запись во все страницы SSD.
2. Реальное количество операций записи, которые совершает контроллер превышает количество команд, которые SDD получает от операционной системы (то самое write amplification, о котором мы с вами говорили).
3. Количество операций очистки блока (erase) больше, чем должно было бы быть при равномерной записи. То есть, при 512-кбайтном блоке, больше, чем одно стирание на 128 команд записи.
Давайте на секунду еще вспомним механизм контроля износа носителя (wear-leveling). В идеале, он должен обеспечивать чтобы все секторы SDD имели равные или очень близкие значения счетчика операций стирания.
Для этих целей мог бы использоваться один из двух крайних подходов:
1. Глобальный wear-leveling. Его еще называют статическим. Находим блок с самым маленьким значением счетчика записи и, независимо ни от чего, пишем информацию в него. Даже если он уже занят. Конечно, если он занят, придется сначала его прочитать (128 операций чтения), очистить его для записи (одна лишняя операция стирания) и записать его на новое место (еще 128 операций записи). Думаю, те, кто внимательно прочитают предыдущее предложение сами придут к выводу, что пользоваться статическим wear-leveling'ом производители почему-то не любят.
2. Динамический wear-leveling. Всё то же самое, только блок для записи ищут среди свободных блоков. Никаких проблем с накладными расходами по перемещению данных из занятого блока, зато другая неприятность - если большую часть диска занимают неизменяемые данные, то эта его часть будет исключена из алгоритма распределения записи по разным блокам и, соответственно, оставшаяся часть будет изнашиваться с удвоенной или утроенной силой.
3. Адаптивный или "передовой" (американцы любят слово "advanced". Наверное за то, что оно ничего не означает). Всё как в динамическом, но время от времени контроллер спохватывается и перемещает данные из блоков с наименьшим износом в блоки с наибольшим.
Этот метод сочетает в себе недостатки обоих предыдущих (накладные расходы по переносу данных и неравномерность износа), но в значительно уменьшенном размере.
Тем не менее, при любом способе wear-leveling'а наибольшее значение счетчика числа операций стирания легко может оказаться в несколько раз больше среднего значения того же счетчика.
Миф второй: SSD не нуждаются в дефрагментации на уровне файловой системы. Обоснование мифа: нет движущихся частей, поэтому скорость записи в любую ячейку одинакова. Как в оперативной памяти.
Кстати, если бы апологеты подобной точки зрения просто заглянули в Intel'овскую документацию, они легко смогли бы обнаружить, что время доступа процессора к оперативной памяти есть величина переменная и как раз очень сильно зависит от адресов к которым надо получить доступ.
Давайте посмотрим чем нам вредит фрагментация файлов (на уровне логических блоков). первое соображение самое простое, не зависящее ни от файловой системы, ни от типа накопителя (HDD, SSD - неважно).
Для доступа к файлу необходимо сначала определить блоки в которых он расположен. А для этого надо прочитать блок с метаданными файловой системы. Чем больше фрагментация файла, тем больше, вообще говоря, операций чтения метаданных надо выполнить.
Как бы быстро не выполнялись операции чтения SSD время на выполнение ДВУХ операций чтения ровно в два раза больше, чем время на выполнения ОДНОЙ операции.
Итак, существуют ли накладные расходы на доступ к фрагментированным файлам на уровне файловой системы? Конечно существуют! Велики ли они? Не-а. Можете смело на них наплевать. Запомните этот аргумент и используйте только для одной-единственной цели - доказывать тем, кто утверждает, что фрагментация значения не имеет, что они глубоко заблуждаются и вообще ничего не понимают в жизни.
Гораздо большее значение имеет другой фактор - при фрагментировании оказываются перемешаны в одном секторе куски разных файлов. А сам файл оказывается распределен по множеству секторов. Поэтому, скажем, его удаление неизбежно приведет со временем к стиранию каждого из этих секторов с предварительным сохранением страниц занятых другими файлами. Представим себе файл размером 2 МБ. Допустим, он не фрагментирован. Значит он располагается в непрерывной цепочке из 4096 логических блоков и его удаление будет для SSD делом крайне простым - отметили все страницы в 4-х секторах как аннулированные и ждем себе пока процедура сборки мусора их очистит. 4 операци стирания - и дело сделано (вопрос о модификации метаданных ФС не затрагиваем).
Теперь представим себе, что он фрагментирован на 20 кусков по 100 кБайт каждый. Контроллер будет
вынужден распределить эти 20 кусков по 20-ти разным секторам. Мы уже говорили - каждый сектор представляет собой непрерывную последовательность из 1024 блоков. Это ограничение схемы трансляции адресов.
Тогда при удалении файла, распределенные ему блоки помечаются аннулированными и, таким образом, мы получаем 20 "грязных" секторов. Причем при повторном распределении логических блоков, которые были отведены удаленному файлу, контроллеру понадобится создавать 20 журнальных блоков, которые рано или поздно придется освобождать, выполнив 20 операций объединения, которые повлекут за собой 2560 операций чтения, 2560 операций записи и 40 операций стирания.
Вдумайтесь! В первом случае мы выполняем 4 операции стирания и добавляем себе в пул 4 свободных сектора. Во втором, мы, наоборот, выделяем 20 секторов из пула, выполняем в десять раз больше операций стирания и, заодно, пять тысяч операций чтения/записи.
Правда страшно звучит?
Но могу утешить - все эти операции при достаточном количестве свободного места на SSD (то есть, при наличии большого числа свободных секторов в пуле) будут спокойно выполнены в фоновом режиме. Вы их даже и не почувствуете.
Правда, возможен еще вариант, что диск забит под завязку - вот тут-то вам уже не отвертеться!
Читал FAQ ссылка на который дана в головном сообщении темы. Очень порадовала первая фраза из этого FAQ:
Цитата:
|
Практически любой SSD на пару порядков лучше обычных HDD на мелких случайных операциях (ибо головку двигать не надо), скорость же линейного чтения не так уж и различается, а вот в несколько потоков уже заметно
|
Использовать SSD для "мелких случайных операций" - оптимальный способ получить неустранимое падение производительности и ускоренный износ. Особенно в несколько потоков - тогда фрагментация (всех видов) гарантирована!
Можно ли бороться с падением производительности, вызванным фрагментацией и как это лучше делать?
Предложение из того же FAQ очень позабавило: "есть возможность вернуть производительность записью всего свободного пространства единицами или нолями".
Господа! Можете следовать этим советам только в одном случае. Если лучшим средством от простуды вы считаете сушеное крылышко летучей мыши и палец повешенного.
Стандартная процедура выглядит несколько иначе. Наверняка её уже где-нибудь неоднократно описывали, но я не нашел и поэтому повторю (вы уж меня извините за банальность): максимально освобождаете SSD, копируя файлы на жесткий диск. В идеале полностью, но не обязательно. Уточняю: не "снимать образ", не копировать посекторно, а обычное тупое пофайловое копирование. Выполняете TRIM всего свободного пространства (чтобы освободить "потерянные секторы"). Копируете файлы обратно. Опять-таки простое копирование, в один поток, файл за файлом. Стандартными средствами ОС.
Сразу хочу сказать, что на 100% это проблему решить не может даже в принципе. Вы же очищаете только те секторы на которые отображаются логические блоки. А как мы с вами выяснили есть еще невидимый резерв.
Причем происходит постоянная ротация - секторы из резерва распределяются под данные, а освободившиеся от данных поступают в резерв. Поэтому, даже выполнив TRIM всего диска мы не решаем проблему полностью - секторы в резервных областях не будут затронуты.
Если нашелся уважаемый участник форума, который прочитал все мои сообщения (такое трудно представить, но допустим), он легко поймет идею лежащую в основе "народного метода" по заполнению свободного пространства произвольными данными. Они хотят уменьшить свободное пространство на диске до нуля, чтобы заставить контроллер выполнить операции объединения и сборки мусора. Правда, никак не могу понять зачем им для этого понадобилось стороннее ПО. Достаточно было закачать на диск один или несколько файлов до полного исчерпания свободного пространства - результат был бы тот же самый.
P.S. Вопреки тому, что мне только что сказали, FTL в данном контексте это НЕ "faster than light", а l2p - не "learn to play"!
