[AMDBulldozer]

В CrystalDiskMark при проходе теста скорости, выбрав размер файла 500Мб скорость записи падает в 2 раза от изначальной(писал об этом ранее), а при проходе теста с размером файла 100Мб скорость записи возвращается к своему максимуму. »

Я Вам не очень рекомендовал бы проводить подобные тесты. Вы можете практически необратимо угробить SSD. Но не из-за превышения числа операций стирания блока. Хотя всевозможные подсчеты времени жизни диска и показывают его способность работать якобы по 10 лет, на самом деле все эти подсчеты - чистая фикция. Они основаны на не соответствующем действительности предположении, что число операций записи во все страницы диска будет одинаково.
Но даже несмотря на это, износ NAND это отнюдь не главная опасность для SSD.
Реальная проблема, которая неизбежно приводит к снижению как скорости чтения (в меньшей степени), так и скорости записи (очень сильно) - это фрагментация дискового пространства.
Причем способов борьбы с такой фрагментацией крайне мало и ни один не является 100% эффективным.
Любые тесты осуществляющие случайную запись на диск, либо использование программ, осуществляющих такую запись (к примеру торрент-клиентов) быстро и эффективно приведет к необратимому снижению производительности работы твердотельного диска.

Интересно, что этот очевидный факт почему-то редко упоминают в обзорах SSD. Напротив, очень часто можно встретить забавные фразы о том, что "в отличие от HDD, для SSD фрагментация не является проблемой поскольку время доступа к любой ячейке у него одинаково".

P.S. Только не надо, прочитав это сообщение, бросаться запускать штатный дефрагментатор ОС - вместо того, чтобы исправить проблему, он её резко усугубит. Еще раз повторю, что использовать программы вроде defrag на SSD ни в коем случае нельзя.

[AMDBulldozer]

P.S. Если кому-нибудь будет интересно, я могу рассказать о том, что из себя представляет фрагментация на SSD, чем она принципиально отличается от фрагментации файлов в файловой системе, почему она приводит к снижению (иногда очень значительному) производительности диска и почему стандартные средства ОС успешно устраняют фрагментацию файлов в файловой системе, но только увеличивают степень внутриблоковой фрагментации.

Как всем хорошо известно, SSD имеет минимально адресуемую единицу данных - страницу, размер которой в большинстве случаев составляет 4096 байт полезной информации (плюс служебная, которая пользователю не видна. так же, как и на жестких дисках). Кроме страницы, существует блок - минимальная единица данных к которой применима операция стирания (erase).
Блок чаще всего состоит из 128 страниц и имеет, таким образом, величину в 512к.

Примечание: иногда в англоязычной литературе вместо термина "страница" используется термин "блок", "блок" называют "сектором", а потом еще просят не путать его с сектором на HDD, который синонимичен блоку и аналогичен странице SSD. Единственной целью такого разъяснения, как мне кажется, является желание окончательно запутать читателя.

Прошу прощения за то, что повторяю всем известные азы, но возможно кто-нибудь из уважаемых участников форума уже успел это позабыть.

Пользователю твердотельный диск представляется непрерывной последовательностью логических блоков, начиная с 0. Эти блоки должны иметь взаимно однозначное отображение на физические страницы диска. Каждой странице должно соответствовать 8 512-тибайтных логических блоков.
А физическому блоку SSD, который имеет размер 512к, и с которым я вас, надеюсь, окончательно сбил с толку, должно соответствовать 1024 512-ти байтных логических блоков. Причем адреса этих логических блоков должны быть строго последовательны, то есть не иметь нарушений последовательности, дырок, смещений и тому подобное.
Блок содержащий логические блоки "0, 1, 2, 3 ... 1023" не фрагментирован. А блок "8, 9, 10, 11, 12, 13, 14, 15, 0, 1, 2, 3... 1023", как легко видеть, фрагментирован.
Если количество фрагментированных блоков достигает определенного, относительно небольшого предела, контроллер, которому некуда будет записывать новый фрагментированный блок, приступит к процедуре "объединения" (merging), которая, в худшем случае, потребует 128 операций чтения, 128 операций записи и 2 операции стирания.
Понятно, что на производительности диска это скажется самым не лучшим образом.

Примечание: в данном случае, как легко видеть, я предполагаю, что контроллер использует какой-то из гибридных алгоритмов FTL. К примеру, FAST. Во всех известных мне SSD реализован какой-то из гибридных алгоритмов (их несколько и все они служат одной цели - уменьшить количество операций объединения).
Но если, к примеру, производитель решил воспользоваться каким-то другим типом алгоритма преобразования логических номеров секторов в физические, к примеру DFTL (FTL on demand), результат будет тем же, только механизм немного другой.

Да, кстати. На всякий случай напомню: FTL - это аббревиатура от "flash translation layer". Промежуточное ПО, которое выполняет три задачи. Кроме собственно преобразования адресов оно занимается еще сборкой мусора (блоков, помеченных на удаление, но не удаленных) и тем самым wear leveling о котором так много любят говорить, когда речь заходит о flash-памяти. Конечно, забота о переназначении дефектных блоков лежит на нем же, но вряд ли имеет смысл выделять его в отдельную задачу - ведь это всё та же трансляция адресов.

[AMDBulldozer]

Итак. Поговорим немного о трансляции адресов. В некотором смысле доступ к логическому блоку на SSD отличается от доступа к такому же блоку на HDD. И это различие принципиально неустранимо.
Позвольте мне для начала привести понятную аналогию. Допустим, у Вас есть камера хранения. Все ячейки в ней пронумерованы и собраны в шкафчики с прямоугольной сеткой отделений.
Тогда, чтобы найти ячейку с нужным номером, Вам не придется просматривать их все - Вы элементарно сможете подсчитать, что она "третья слева в пятом сверху ряду второго шкафчика".
Понятно, что это привычный всем нам метод адресации, который абсолютно одинаково работает и в жестких дисках, и в микросхемах ОЗУ.

Примечание: понятно, что приведенное выше высказывание не является абсолютно точным. Пользователь имеет доступ не к физическим, а к логическим блокам жесткого диска и контроллер диска хранит в служебных областях (на "отрицательных цилиндрах") некоторый достаточно простой и совершенно статический, если не считать списка переназначенных в процессе работы секторов (G-листа), транслятор. Точно так же, любой процесс имеет доступ не к физическим, а к логическим адресам памяти. Теоретически, конечно, это не обязательно - страничную организацию памяти можно и отключить, но на практике все операционные системы всегда её используют. Кроме совсем уж древних, таких как MS-DOS или Xenix. Обе от Microsoft. Да, и конечно код исполняющийся в SMM-режиме тоже игнорирует страничную адресацию. Но его ведь нельзя назвать процессом, верно?

Резюме: если пытаешься рассказать о чем-то не приблизительно, а с максимальной точностью, рассказ неизбежно обрастает кучей ненужных подробностей, становится длинным, нудным и вообще никому не интересным.
Поэтому, я надеюсь, меня простят, если в дальнейшем я буду опускать некоторые подробности и не отвлекаться на специальные случаи.

Теперь рассмотрим хранение информации на твердотельном накопителе. Чтобы избежать преждевременного износа поверхности, мы не можем установить статическое соответствие между номерами физических ячеек и логических блоков.
Значит, в каждой ячейке нам придется хранить не только само содержимое логического блока, но и его номер.
Номер блока, таким образом из механизма прямой адресации превращается в метаданные (данные о данных), которые сами по себе надо разыскивать.
Как это организовать в камере хранения? Самый простой способ - прикреплять к каждой ячейке ярлык, на котором записан этот самый логический номер блока и потом искать его во всех ячейках, пока не найдешь. Или не найдешь.
Понятно, что при этом надо было бы при любой операции доступа к диску читать весь диск от начала и до конца.
Производительность была бы ужасающе низкой и едва ли пользователей соблазнила бы перспектива покупать диски, каждое чтение/запись которых занимает 1-2 минуты.
Вариант с прямым отображением (каждому логическому блоку соответствует физический блок с тем же номером) мы уже отвергли как непригодный с точки зрения износа. Хотя износ - не единственная причина. Представьте себе, что Вы решили изменить содержимое одного какого-то блока.
Как это происходит в HDD? Самым естественным образом - мы его читаем, редактируем, записываем обратно. Как это будет выглядеть на SSD с прямым отображением? Мы читаем страницу, редактируем... И тут выходит осечка - чтобы повторно выполнить запись уже записанной ранее страницы, надо сначала её стереть. Причем не только её, а все 512к физического блока, который состоит из 128 страниц.
Но в этом блоке, скорее всего, занято больше, чем одна страница. Поэтому мы должны сначала прочитать все занятые страницы (до 128 операций чтения), стереть блок и записать страницы обратно (до 128 операций записи).
Поверьте мне на слово - это будет очень долго. К тому же, каждая запись будет вести к износу NAND. Один раз перезаписали эти 512к - выполнили 1024 операции стирания (если писали по одному 512-байтовому блоку). Три-пять перезаписей - и блок труп.
Итак, прямое отображение не годится. Конечно, можно немного улучшить ситуацию, используя очередь комнд (NCQ), чтобы писать не по одному блоку, а по несколько, но, сами понимаете, принципиально положения это не улучшит.

Что тогда делать? Можно одним махом решить все проблемы - хранить где-нибудь таблицу соответствия логических блоков физическим! Тогда любой логический блок можно будет записать на абсолютно любое место, что разом решает почти все проблемы. Конечно, хранить такую таблицу можно только в очень быстродействующем запоминающем устройстве, которое, к тому же, не имеет ограничений по числу записи. Но у нас уже давно есть такое устройство! Это обычная DRAM. Поставим микросхемку памяти на диск - всё равно контроллеру нужна своя RAM для работы.
И понадобится этой памяти не так уж много. Давайте посмотрим - диск у нас, ёмкостью, допустим, 128ГБ, мы хотим хранить данные о каждом 512-тибайтном логическом диске. Адрес блока 32-битовый, то есть нам надо всего 4 байта RAM на каждый блок. 4/512 = 1/128. Меньше одного процента от ёмкости диска. Значит на 128 ГБ-ный диск нам потребуется... потребуется... ЦЕЛЫЙ ГИГАБАЙТ ПАМЯТИ?!! Только для хранения L2P таблицы?!! (L2P - "logical to physical". Таблица трансляции адресов блоков. Составная часть FTL.)
Нереально. Это будет стоить слишком дорого. К тому же, приведет к резкому увеличению энергопотребления диском.
Можно, конечно, установить соответствие не между логическим блоками, а между 4096-байтными страницами. Требуемый размер RAM уменьшится в 8 раз, но всё равно останется запредельно большим.
Итак, полностью ассоциативное отображение - тоже не вариант.
Что делать? Как решить эту новую, возникшую только с появлением SSD проблему? Постойте... А настолько ли она новая?
Вспоминается мне, что я уже читал о чем-то подобном. В частности, в статьях про устройство процессора. Вспомнил!
Это же кэш-память! Она устроена абсолютно так же. Только в процессоре количество кэш-памяти меньше размера ОЗУ, а в SSD количество логических блоков равно количеству физических.
Лезем в интернет за инфомации об устройстве кэш-памяти и выуживаем оттуда не очень понятное, зато очень весомо звучащее словосочетание "частично-ассоциативный кэш". И решение сразу становится очевидным. Будем хранить в памяти не таблицу соответствия 512-байтовых логических блоков, и даже не 4096-байтовых страниц, а 512-кбайтных физических блоков. Той самой минимальной единицы для операции erase.
Сколько в этом случае потребуется RAM для хранения L2P таблицы? 4 байта RAM на 512к объема диска... Получается 1 мегабайт. Это легко можно себе позволить. Можно позволить даже больше. Итак, останавливаемся на поблочном отображении? К сожалению, тоже нет. Мы сейчас рассматриваем уже третий вариант установить отображение логических блоков на физические и ни один из них не применяется ни в одном из известных мне SSD.
Прямое отображение, полностью ассоциативный кэш, частично ассоциативный кэш - ни один из этих вариантов не подходит. Кстати, почему производителям не подошел так удачно придуманный нами вариант с частично ассоциативным кэшем? Причины старые - износ и скорость доступа. В полностью ассоциативном кэше мы можем тупо записывать страницу с одним и тем же номером (то есть один и тот же логический блок) снова и снова, но каждый раз контроллер SSD будет производить запись на новое место. Все ячейки (точнее 512-кбайтные блоки) будут изнашиваться одинаково и количество операций записи в каждую ячейку будет одинаковым.
В частичном ассоциативном кэше контроллер тоже каждый раз будет производить запись в новую страницу. Вот только если в предыдущем случае это могла быть любая страница и в 512-ти кбайтный блок происходило 128 записей до его заполнения и перехода к следующему блоку, в частично-ассоциативном в каждом блоке есть только одна страница пригодная для записи логического блока с данным адресом. Поэтому каждая последующая запись будет происходить в новый 512-ти кбайтный блок и, когда свободные блоки закончатся, на каждую операцию записи будет приходиться одна операция стирания. В то время как в полностью ассоциативном кэше 1 операция стирания приходилась на 128 операций записи. Результат понятен - износ больше, скорость меньше. Не совсем то, чего мы хотели, правда?
Вот если бы удалось как-нибудь совместить... Если бы износ был такой же маленький как в полностью ассоциативном кэше, а L2P таблица такая же крохотная как в кэше с посекторной ассоциативностью (сейчас я использовал термин "сектор" вместо "512-ти килобайтный блок". Просто, чтобы хоть немного запутать читателя, которого не удалось заставить бросить чтение раньше). В общем, хорошо бы придумать что-нибудь такое эдакое, чтобы всем было хорошо.
Глупо звучит, правда? Но на практике, именно такие гибридные алгоритмы, которые сочетают в себе черты полностью ассоциативного кэша и частично ассоциативного кэша, действительно были созданы и именно они-то и используются на практике во всех известных мне SSD.

Резюме для тех, кто нашел в себе силы дочитать до конца (надеюсь, таких не найдется): в этом ужасно длинном сообщении очень много букв, но нет ответа ни на один из поставленных ранее вопросов. Что такое внутриблоковая фрагментация? Чем она вредна и почему против неё бессильна программа defrag? Как накопитель вообще отличает свободные страницы от занятых? Что он делает, когда свободных страниц не остается? И при чем тут вообще Windows XP? (при чем-то она должна быть, раз все сходятся на том, что SSD с этой ОС работает плохо).

Ждите ответа в следующей серии. Если меня раньше не забанят за флуд в прикрепленной ветке.

[AMDBulldozer]

Итак, пока меня вроде не пытаются остановить, так что продолжу излагать внутреннее устройство 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 и без меня это всё знают, а тем, которые покупают по принципу "мне вон тот зелененький, он мне по цвету к корпусу подходит", технические детали даром не нужны.

[Coutty]

Пиши-пиши, весьма занятно.

[AMDBulldozer]

Итак, продолжим рассказ об FTL.
Мы с вами уже договорились, что будем разбирать только наиболее общие принципы, а всевозможных ухищрений, к которым прибегают производители, касаться не станем - их слишком много, все они слишком плохо документированы и рассказ даже о тех, которые я знаю (а это лишь небольшая их часть) занял бы чересчур много времени.

Когда говорят о блоках (они же "секторы") 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 эта заметка кому-то возможно помогла получше уяснить.

[AMDBulldozer]

Я приношу глубокие извинения, но всё-таки дополню своё сообщение теми выводами, ради которых это длинное изложение и было написано.

Во-первых, мы можем видеть, что механический подсчет продолжительности жизни 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"!

[westland77]

AMDBulldozer,

Все мозги разбил на части,
Все извилины заплёл,
И канатчиковы власти
Колют нам второй укол.

Уважаемый редактор,
Может лучше про реактор,
Про любимый лунный трактор.....

[Radeo]

Ого! Спасибо!

[AlexLevin]

AMDBulldozer,
Спасибо, очень поучительно. Давно работаю со многими разными SSD, но узнал много нового. Наверно эта информация очень полезна разработчикам, работающим на уровне плат, узлов и т.п.

Для ассемблеров систем было бы неплохо иметь надежные (насколько это вообще возможно) статистические данные по долговечности и деградации во времени SSD разных типов разных производителей. Да еще бы с разбивкой по видам использования (типа: серверы разного назначения 24х7, оффисные компьютеры, персональные для игр и видео, персональные для периодического пользования).

Вот если бы кто-то выложил такие данные - то им бы цены не было.