а скорость загрузки других программ тебя не интересует? Или просто других не будет?
Короче: если рассчитываешь, что SSD тебе нужен на 15 и более лет - виндовс тоже туда не ставь: реестр в ней постоянно изменяется, не ровен час - помреть накопитель-то. Или положи его на полку - он тогда навсегда останется максимально работоспособным с нулевым износом.
На правах модератора восстанавливаю удаленный участником обсуждения WSonic
Итак, пока меня вроде не пытаются остановить, так что продолжу излагать внутреннее устройство SSD на уровне микропрограмм контроллера.
Для начала хочу честно всем сказать, что предыдущее сообщение можно вообще не читать. Оно целиком и полностью было посвящено единственному вопросу: почему из всех возможных схем трансляции адресов наибольшее распространение получили именно гибридные схемы (если не забуду, потом еще расскажу про DFTL. Для общего развития).
Еще одна веская причина не читать предыдущее сообщение состоит в том, что после публикации я его прочитал и ужаснулся количеству орфографических ошибок, пропущенных знаков препинания и откровенно плохой стилистике.
Конечно, если бы я его предварительно вычитал, такого бы наверное не было, но чукча не читатель!
Итак, вернемся в гибридной схеме FTL. В чем она заключается? В том, что для трансляции адресов применяются не одна, а две таблицы. Первая из них транслирует адреса с дискретностью равной размеру блока (принимаем равной 512кБ, хотя встречал и 256к, и 1024к). А с помощью второй реализуется тот самый полностью ассоциативный кэш, который отличается наибольшей производительностью и наилучшим контролем износа (wear-leveling), но требует слишком много оперативной памяти. Поэтому, поступим так, как всю жизнь делали разработчики кэш-памяти - сделаем эту таблицу достаточно маленькой. В результате мы получим, что подавляюще бОльшая часть диска должна состоять из нефрагментированных 512-ти килобайтных блоков (их еще называют блоками данных - data-blocks), но некоторые блоки могут иметь прямое постраничное (4096 или, редко, 8192 байта) отображение и порядок следования логических блоков в этих секторах не имеет значения. Их называют журнальными блоками (log-blocks).
Позволю себе напомнить, что основным достижнием разработчиков SSD является созданная ими терминологическая путаница. Так, слово "блок", о чем мы уже говорили, может значить как логический 512-тибайтный блок, используемый в общеизвестной схеме адресации LBA, так и физический 512-ти килобайтный блок на SSD. Чтобы избежать чересчур частого повторения слова "блок" в разных контекстах, я буду периодически называть 512-ти килобайтный блок "сектором".
Итак, что нам дает наличие двухуровневой схемы трансляции?
Представьте себе, что Вы только что приобрели новенький SSD-диск. Первое, что Вы делаете, это создаете на нем таблицу разделов. Разделов MS-DOS, разумеется. Не GPT же на нем создавать?
То есть записываете MBR. Что происходит на SSD? Контроллер записывает в начало любого свободного блока на диске одну страницу (4096 байт) в которой реально заняты только 512, а остальные 7/8 объема пустуют. В таблице L2P создается запись, которая сообщает контроллеру, что данный сектор является блоком данных (размером 512к) и что в нем хранятся логические сектора с номерами от 0 до 1023. Одновременно модифицируется еще одна служебная таблица в которой записанная страница отмечается как занятая.
Кроме собственно данных в эту страницу записывается также служебная информация. Что это за информация? Номера логических блоков, которые хранятся в этой странице, флаг "занято" отмечающий тот факт, что страница хранит данные и еще один флаг, который используется для определения того, насколько часто данный логический блок перезаписывается системой. В англоязычной литературе логический блок содержащий часто изменяемые данные называется горячей ("hot"), а редко модифицируемые - холодной ("cold").
Вы можете спросить, зачем это вообще нужно? Ведь каждый сектор имеет свой собственный счетчик числа выполненных операций стирания (erase). А иногда даже два счетчика - общий счетчик числа стираний и счетчик недавних стираний.
И что по числу стираний легко понять насколько часто изменяются данные в странице. Что на это можно ответить?
Верно, данные по состоянию носителя страницы мы всегда легко можем получить. Но логический блок не хранится постоянно в одной и той же странице. После каждой модификации он записывается на новое место. А зачастую записывается на новое место и безо всякой модификации. Если контроллер знает, что блок содержит редко изменяемые данные, он запихнет его в более изношенный сектор. Если данные меняются часто - подберет для него сектор получше.
Итак, мы с Вами создали на 128 гигабайтном SSD раздел. Естественно, отвели для него всё имеющееся на диске место.
Полюбовались плодами своих трудов. Подумали. Заглянули в интернет. Прочитали там, что когда SSD остается мало свободного места, его производительность начинает резко падать. Точнее, падать она начинает когда на диске остается процентов 40 свободного пространства, а после того как осталось 10% падение может принять ужасающие масштабы.
Именно о причинах этого падения мы с вами сейчас и говорим.
Падение скорости записи всегда проявляется гораздо более существенно, чем падение скорости чтения.
Сразу оговорюсь: я охотно верю, что среди читателей данного сообщения (если они вообще будут) найдется немало людей, которые гордо скажут "брехня", гордо покажут снимок экрана дефрагментатора, который отметит, что файловая система фрагментирована на 50% и заявят, что никакого снижения производительности они не замечали и никогда не заметят. Отвечу заранее - такие люди говорят о фрагментации на уровне логических блоков. А мы говорим о физических. Это разные вещи.
Обычно мы ожидаем, что компьютер в точности делает то, что мы от него требуем и ничего сверх этого. Дали команду записать блок - он выполняет одну команду записи. Для SSD, к сожалению, это не так. Одна команда записи логического блока, может вылиться в пару сотен команд записи-чтения. Естественно, такие случаи редки и FTL делает всё для того их было как можно меньше. Тем не менее, в среднем на одну команду записи выданную контроллеру приходится большее количество команд, которые он выполняет. Отношение числа выполненных команд к числу выданных называетcя "усилением записи" (write amplification). Чем больше этот показатель - тем меньше производительность SSD.
Рост "усиления записи" внешне проявляется как деградация производительности.
Итак, взвесив все "за и "против", мы решили пожертвовать объемом ради того, чтобы производительность не снижалась по мере заполнения диска. Для этого мы уменьшаем только что созданный раздел со 128 до 100 ГБ. Оставить примерно 20% объема диска не распределенным - хороший способ застраховать себя от проблем, которые могут возникнуть по ходу эксплуатации. Правда это мало кто делает. Диски дорогие, объемы маленькие и жертвовать пятой частью диска просто ужас как жалко!
Тем не менее, мы это сделали. Внесли изменения в таблицу разделов и записали новую версию MBR на диск.
Что происходит на SSD? Диск отмечает страницу с первоначальной версией MBR как "удалённую", записывает в следующую за ней страницу измененный нами вариант, меняет статус этой страницы со "свободно" на "занято" и создает в l2p-таблице страничного уровня запись о том, что нулевой логический блок отображается в первую страницу такого-то сектора. То есть, раньше он отображался в нулевую страницу, а теперь отображается в первую. То есть, сектор фрагментирован и теперь из "блока данных" превращается в "журнальный блок".
На самом деле, конечно, я сейчас описываю только один из возможных вариантов. Каждый производитель использует собственный алгоритм, детали которого обычно не раскрываются. Контроллеры SandForce производят сжатие данных перед записью их в NAND и, тем самым, могут иметь write amplification меньше единицы, что невозможно при других условиях. А Intel X25-M с целью повышения производительности использует закрытый (proprietary) протокол "объединения записи" (write combining) при котором данные сначала накапливаются в буфере, а затем записываются так, чтобы по возможности производить запись сектора целиком.
Это очень хороший алгоритм, он позволяет на новых дисках показать приличный прирост скорости записи. И если диск используется не слишком интенсивно, пользователь скорее всего даже не заметит небольшого недостатка данного алгоритма. Недостаток состоит в том, что объединение в одном секторе данных из разных файлов при интенсивной работе ведет к резкому (более, чем в два раза) снижению производительности. Диск может "задумываться" на какое-то время и не реагировать на команды, пока не разгребет и не переместит фрагментированные секторы.
Однако, еще раз подчеркиваю, что этот эффект замечают только те пользователи, которые интенсивно используют дисковую подсистему. В домашних условиях диск будет бОльшую часть времени простаивать или работать на чтение, поэтому краткие периоды активности, во время которых контроллер будет приводить в порядок свои данные, скорее всего останутся незамеченными.
Сейчас сожру чего-нибудь и продолжу.
А может это на фиг никому не надо? Те, кто интересуется SSD и без меня это всё знают, а тем, которые покупают по принципу "мне вон тот зелененький, он мне по цвету к корпусу подходит", технические детали даром не нужны.
Хм... А SSD для чего покупали то? Типа купите стиральную машинку, но полоскайте белье вручную в корыте и отжимайте тоже руками, ибо, полоскание пустое растранжиривание ресурса СТИРАЛЬНОЙ машины... а отжим... отжим это вообще... во сколько раз подшипник быстрее износится... ужас...
Мы с вами уже договорились, что будем разбирать только наиболее общие принципы, а всевозможных ухищрений, к которым прибегают производители, касаться не станем - их слишком много, все они слишком плохо документированы и рассказ даже о тех, которые я знаю (а это лишь небольшая их часть) занял бы чересчур много времени.
Когда говорят о блоках (они же "секторы") SSD часто употребляют аналогию с перезаписываемым оптическим диском.
На него можно писать маленькими порциями, но стирать его надо целиком, причем в процессе стирания и перезаписи он постепенно повреждается. Не могу сказать, что это аналогия совершенно точна (в некоторых, очень специальных случаях, можно произвести повторную запись в уже записанную страницу NAND, не прибегая к предварительному стиранию, результат этой операции будет равен побитовому логическому "ИЛИ" между уже записанной и записываемой информацией), но, поскольку мы уже договорились, что специальные случаи оставим в стороне, то будем активно ей пользоваться.
Итак, у нас есть некоторое количество "журнальных блоков", страницы которых могут соответствовать произвольному набору логических блоков и есть все остальные блоки - "блоки данных", которые обязаны соответствовать непрерывной последовательности в 1024 логических блока.
При этом никакой физической разницы между журнальными блоками и блоками данных нет. Любой блок может в разные моменты времени относиться то к одному, то к другому типу, в зависимости от того, содержит ли он страницы из L2P таблицы страничного уровня (того самого "полностью ассоциативного кэша").
В связи с ограничением по объему памяти, занимаемой L2P таблицей только незначительная часть блоков могут быть "журнальными". Так что свободные журнальные блоки быстро закончатся (точнее, закончится место в их L2P таблице).
После того как это произойдет, контроллер на некоторое время прекратит принимать команды и займется освобождением журнальных блоков. Для этого используется процедура, называемая "объединение" (merging). Возможны три варианта с помощью которых контроллер может освободить журнальный блок.
Первый из них - самый идеальный. Если блок формально считается журнальным, но фактически содержит непрерывную последовательность блоков, его надо просто переименовать в блок данных и дело готово. Соответствующие ему записи в страничной L2P таблице уничтожаются и тем самым освобождается место для объявления журнальным какого-нибудь другого блока. Ситуация хорошая, но, увы, малоправдоподобная.
Второй вариант - у вас есть непрерывная последовательность логических блоков, несколько из которых были изменены.
Допустим, до момента изменения, эти логические блоки хранились в блоке данных. Напомню, что "блок данных" - это противоположность "журнальному блоку". То есть сектор, к которому не применяется операция постраничного отображения. Этот блок данных не изменяется вообще. Ничего там не изменяется, ничего оттуда не стирается. Просто измененные страницы отмечаются контроллеров в системной таблице как недействительные (invalidated).
Вообще страница может иметь три состояния: свободна, занята и недействительна.
А измененные страницы сохраняются в другом блоке (журнальном). Если в такой ситуации у нас возникает необходимость освободить журнальный блок, мы считываем все страницы помеченные как "занятые" из исходного блока, измененные варианты из журнального блока, записываем всё, что получилось, в свободный сектор, который помечаем как занятый, а на все скопированные в этот сектор страницы ставим черную метку: "недействительны".
128 операций чтения, 128 операций записи - и журнальный блок освобожден!
Дороговато, правда? Контроллер пытается уменьшить время выполнения этой операции, записывая, по возможности, измененные страницы в журнальный блок с теми же смещениями, которые они имели в блоке данных.
Если в этот журнальный блок больше ничего не записывалось, можно просто прочитать неизмененные страницы из исходного блока данных и переписать их в журнальный блок. После этого журнальный блок, как мы это уже делали, переименовывается в блок данных и в таблице освобождается место для еще одного журнального блока.
Тут возникает естественный вопрос: допустим, в освобождаемом журнальном блоке всего три-четыре занятых страницы. А остальные свободны. Что мы выигрываем по сравнению с предыдущим случаем? Будет 124 операции чтения-записи вместо 128? Невелика разница! На самом деле велика. На каждой такой операции мы выигрываем минимум 2 миллисекунды.
Почему? По одной простой причине. После объединения данных из двух блоков и записи их в третий у нас остаются два грязных блока. То есть блока, информация из которых помечена как аннулированная. Если мы переписываем данные из одного блока в другой, то грязный блок остается только один.
Кстати, кто-нибудь обратил внимание на то, что за всё время мы не выполнили ни одной операции стирания? Мы только читаем, пишем и правим таблички в ОЗУ контроллера.
Понятно, что это не случайно. Именно благодаря такому подходу, мы и получаем сверхвысокую по сравнению с жесткими дисками скорость работы SSD.
Но у нас копится мусор. Информация, которую Вы считали давным-давно уничтоженной, по-прежнему в целости и сохранности хранится на SSD c пометкой "invalidated". Её можно при желании даже оттуда вытащить.
Это на жестком диске достаточно расписать несколько раз случайными числами принадлежащие файлу логические блоки, чтобы надежно скрыть информацию. Когда Вы попробуете сделать это на SSD, логические блоки-то будут теми же самыми. Только вот физические окажутся другими. И файл спокойно продолжит своё существование.
Тут мы подошли к вопросу, а как вообще удалить файл? Имея жесткий диск, Вы просто даете команду "удалить" и все занятые файлом блоки возвращаются драйвером файловой системы в пул свободных.
Причем информация в этих освобожденных блоках спокойно может сохраниться (если Вы явно не дали команду операционной системе расписывать нулями освобождающееся пространство). Какая разница? Кому она мешает?
На HDD никому. Сам контроллер жесткого диска не ведет никакого учета занятых и свободных блоков. Он оставляет это операционной системе.
Применим подобный подход к твердотельному накопителю. Что получится? При записи информации он будет послушно отводить для неё блоки из числа свободных, а при удалении файла эти блоки не будут освобождаться. Получится забавная ситуация - с точки зрения пользователя у него диск пуст на 90% (он считает, что всё удалил), а SSD работает страшно медленно, потому что контроллер искренне верит в то, что у него вообще нет ни одного свободного блока.
Конечно, контроллер не совсем дурак и у него есть невидимый запас. Микросхемы флеш-памяти имеют объем кратный 1024 (или двойке в любой другой степени). А диск, к примеру, может иметь объем кратный 1000. Вот эта разница между круглым двоичным числом и круглым десятичным и составляет "неприкосновенный запас" контроллера.
Имея этот запас, он еще кое-как, хоть и очень плохо, может предпринимать меры по уменьшению износа носителя, выделять из него журнальные блоки, переназначать вышедшие из строя, хранить в них копии таблиц на случай отключения питания (если бы таблицы создавались каждый раз заново, то только для инициализации SSD в момент включения потребовалось бы несколько минут).
Короче говоря, запасных ячеек мало, а нужны они постоянно. Поэтому нужно иметь какую-то возможность сообщить контроллеру, что какой-то диапазон логических блоков освобожден (к примеру, в результате удаления файла).
Для этого операционная система передает контроллеру введенную специально для SATA SSD команду TRIM. Или WRITE SAME с установленным битом UNMAP для SSD с SAS-интерфейсом.
И тут мы получаем наконец ответ на вопрос "почему SSD плохо работают с Windows XP". Думаю, все уже поняли сами - эта ОС не передает команду TRIM, поэтому диск ни при каких условиях не освобождает блоки и диск очень быстро оказывается заполнен на 100%. Со всеми вытекающими отсюда последствиями.
Хотите использовать SSD под windows xp? Нет проблем! Заранее оставьте на диске некоторое количество нераспределенного пространства и никогда его не используйте.
Но, продолжим с командой TRIM. В её описании сказано, что эта страшная команда уничтожает все данные в указанных секторах, что при её использовании надо быть крайне осторожным и что вообще вручную её использовать крайне не рекомендуется. Пусть ОС её пользует. Удалит чего-нибудь не то - сама будет виновата.
Правда ли всё это? НЕТ!!! Вас опять обманули.
TRIM, как легко понять, вообще ничего не уничтожает. Он просто помечает страницы, содержащие удаляемые блоки тэгом "недействительные". Если Вы попытаетесь что-нибудь прочесть из блока который попал в диапазон TRIM, то увидите одни нули. Проверено! Но на самом деле, контроллер вообще не стал выполнять никакого чтения - он сверился по таблице, что данных в указанном блоке быть не должно и вернул вам нули, которые сам и сгенерировал.
Такой вот наглый обман потребителей...
Настало время для последнего вопроса: ну так хоть когда-нибудь контроллер хоть что-нибудь стирает или информация попавшая на SSD остается там навечно?!
И тут я могу ответить со всей прямотой - стирает!. Иногда. Когда ему делать нечего. И это не шутка. В то время, когда пользователь дает контроллеру работу (чего-нибудь читать или чего-нибудь писать), тот старается не запускать такие длинные операции как очистка блока, которая занимает, как я уже упоминал, около 2 мс.
Он берет свободные блоки из пула и возвращает туда грязные (помеченные тегом "invalidated").
Когда у контроллера выдается свободная минутка, он запускает процедуру "сборки мусора" (garbage collection). Мы о ней уже упоминали как об одной из составляющих FTL.
Алгоритм запуска процедуры может быть достаточно сложен и зависеть от множества факторов - количество "грязных" блоков (при превышении определенной границы в процентах от общего числа процедура запускается автоматически), исчерпание запаса свободных блоков, пылевая буря на Марсе... Обычно производители очень неохотно раскрывают используемый ими механизм сборки мусора. Потому что именно разделение по времени уборки этого самого мусора и выполнения операций ввода-вывода и позволяет SSD показывать такие замечательные результаты.
О чем я еще обещал написть, но не написал? Только о DFTL? Да ну его на фиг этот DFTL! Думаю, основной принцип работы SSD эта заметка кому-то возможно помогла получше уяснить.
Дык вас консультируют. ShaddyR ссылки дает что почитать. Я вот тоже личным опытытом делюсь. Но вы уж как то избирательно выхватываете какие то... ну скажем так - неоднозначные советы... я про перенос темпов на HDD.. Да и вообще - тему то почитайте, она вроде вся о том, что вас интересует. Может и не придется в сто первый раз одно и то же пережевывать...
Цитата Cooc:
А вот интересно, полезно ли на SSD при " разметке "
Да, конечно. Хотя можно добиться того же эффекта, постоянно следя на количеством свободного места в разделе, но оставить некоторый объем не распределенным разделам в которых созданы файловые системы проще и надежнее.
При этом физические блоки первоначально входившие в нераспределенное пространство всё равно будут использоваться для записи и хранения данных.
То есть, упрощенно говоря, контроллер будет регулярно брать чистые блоки из свободного места, а на их место помещать использованные блоки, имеющие больший процент износа (на самом деле там основное значение имеет даже не износ ячеек, как счетчик числа операций очистки блока, а чисто логическая внутриблоковая фрагментация, но на эту тему уже неоднократно писали).
Спасибо, очень поучительно. Давно работаю со многими разными SSD, но узнал много нового. Наверно эта информация очень полезна разработчикам, работающим на уровне плат, узлов и т.п.
Для ассемблеров систем было бы неплохо иметь надежные (насколько это вообще возможно) статистические данные по долговечности и деградации во времени SSD разных типов разных производителей. Да еще бы с разбивкой по видам использования (типа: серверы разного назначения 24х7, оффисные компьютеры, персональные для игр и видео, персональные для периодического пользования).
Вот если бы кто-то выложил такие данные - то им бы цены не было.
Ну я же просил без острот, что, звёздная болезнь заела ? Я, между прочим, начинающий пользователь и ваш форум вы создавали в основном для консультаций таких как Я. Так в чём же дело,куда вас понесло ?
1. Возможно, что пользователь вы и начинающий, но хам достаточно зрелый. "ваш форум вы создавали в основном для консультаций таких как Я" - утверждение неверное. Такие как вы должны сначала освоить базовые понятия, чтобы задавать осмысленные вопросы и отучиться хамить.
2. Прочтите всю ветку. Внимательно. Там уже есть ответы практически на все ваши вопросы. Ваша лень или занятость читать всю ветку не может служить вам оправданием. Здесь все люди занятые и обучать вас азам не обязаны.
3. Вам дали несколько разумных советов, но вы даже не пытаетесь их внимательно изучить, а пытаетесь этих людей оскорблять.
4. Подучите Русский язык: "баз грамотный трёп". Если "а" опечатка, то раздельное написание - ошибка. Надо писать "безграмотный трёп". И если он вам надоел, то прекратите им заниматься, не задавайте безграмотные вопросы. Хоть вы и начинающий, минимальные базовые знания следует получать не на форумах, а в книжках для начинающих.
5. По сути вопроса - для использования всех преимуществ SDD ничего с него никуда не нужно переносить. Ничего. Все программы, рабочие файлы и временные папки оставте на нем. После установки ОС проверьте правильность установки параметров, чтобы ОС не пыталась "улучшать" работу SSD, как она это делает для HDD. Все детали настройки ОС есть на форуме. Забудьте про "износ" SSD. Чем меньше вы будете его "оптимизировать", тем быстрее и дольше он будет у вас работать.
5. Используйте HDD для хранения больших файлов и данных (фото, видео, аудио, большие базы данных и т.п. Делайте на HDD регулярно бэкап вашего SSD. Если вы будете использовать свой компьютер в среднем по 8 часов в день, то вам хватит вашего SSD лет на 5 как минимум, а скорее всего он проработает дольше (ну если конкретно вам не попадется плохой экзэмпляр). А через 5 лет такой SSD будет стоить, условно говоря, копейки и вы его легко замените, если не обновите свой компьютер раньше.
Ввиду ОПК 3.1 и 3.7, участник Cooc получает 2 недели свободного времени на изучение всех ответов и прочтение всех предоставленных ссылок, в том числе во избежание повторения вопросов, ответы на которые есть по ссылкам.
