HDD и SSD – единство различий (страница 3)
реклама
Стирание блока
Увы, разработчики не забыли о нас, простых смертных. Сделать стирание произвольной страницы было бы слишком просто для использования, этого они позволить не могли, видимо. Стереть выбранную страницу не получится, эту операцию можно сделать только над блоком ... который состоит из множества страниц. Ладно, без лирики, а то цензура не пропустит.
Время стирания блока самая долгая процедура в NAND. Оно исчисляется единицами миллисекунд. Для сравнения, время программирования страницы порядка 0.3 мс, а время ожидания данных при чтении 20-30 мкс. Понятное дело, что стирается сразу много страниц, ведь блок большой, но все равно долго. И, что особо неприятно, на всё это время будет занята вся плоскость.
Традиционный способ ускорения через буферную память здесь не применяется ввиду очевидной глупости экономии, да и ... при стирании нет нужды передавать данные. Единственный способ ускорить стирание - запустить такую команду на обеих плоскостях одновременно. Очистка будет идти практически в два раза быстрее, но будут заняты обе поверхности, причем на длительный интервал времени. К этому нюансу вернемся позже.
Перемещение данных внутри LUN
Для балансирования нагрузки на страницы, приходится перемещать данные из редко использованных страниц в сильно использованные, а освободившуюся память использовать для интенсивной работы. Среди команд NAND есть несколько, которые позволяют перемещать данные внутри одного LUN, точнее в пределах одной плоскости. Фактически, выполняется связка Read + Write, только данные пересылаются внутри микросхемы самим контроллером плоскости LUN (их пара на LUN, по одному на плоскость). Времени это занимает немногим меньше обычной команды записи, да и функциональность ограничена рамками LUN. Сложно сказать, используют ли контроллеры SSD сии команды, ведь механизм их работы сильно ограничивают возможности по перемещению данных, а выигрыш незначительный.
реклама
Производительность в цифрах
Воспользуемся измерением производительности из "Optimizing NAND Flash Performance", любезно предоставленной фирмой Micron.
Вначале для случая применения одного LUN. Память все та же, MLC.
- Простое последовательное чтение: 27.3 Мбайт/сек;
- Чтение, с использованием кэширования: 36.5 Мбайт/сек;
- Чтение, с использованием плоскостей: 32.4 Мбайт/сек;
- Простая запись: 4.4 Мбайт/сек;
- Запись (точнее, записи) через обе плоскости: 8 Мбайт/сек;
- То же, с использованием буферной памяти: 9.6 Мбайт/сек;
- Стирание блока: 3.5 мсек или 143 Мбайт/сек;
- Стирание по обеим плоскостям: ~3.5 мсек или ~286 Мбайт/сек.
Повышение производительности, вторая часть - много LUN
Производительность одного LUN озвучена выше, что же дальше? Современные SSD обеспечивают чтение данных порядка 200 Мбайт/сек и запись 40-70 Мбайт/сек. Для обеспечения таких скоростей надо как-то одновременно считывать 200/36=6 LUN, а при записи использовать 40...70/9.6 = 5...8 LUN. Причем, последние цифры даны без учета затрат на стирание и перемещение данных внутри SSD для выравнивания нагрузки. Означает ли это, что в современных накопителях Flash памяти повсеместно применяется 5-10 независимых каналов? Отнюдь, это от лукавого!
Ранее было отмечено, что в одном корпусе может находиться несколько независимых устройств хранения информации, а именно - LUN. Организовано это собрание может быть различно, через разные управляющие сигналы выборки CE или/и через старший бит адреса. Но это способ, а суть не меняется - они независимы. Итак, сколько LUN может быть в одном корпусе?
А сколько угодно (почти шутка), стандарт это позволяет. На данный момент больше двух LUN на один target не изготавливают, хотя для этого нет никаких ограничений. В одном корпусе может быть 1-2 target.
Все сказанное относится к тем микросхемам, которые могут встретиться в распространенных SSD. Если брать 'вообще', то и не такие монстры попадаются ... но шанс увидеть их 'в живую' крайне мал.
реклама
Итак, в одном корпусе может быть 1-2-4 LUN. Все эти LUN независимы, что позволяет над ними выполнять то, что ранее делали с плоскостями - запустить команды одновременно на нескольких устройствах. При этом полная производительность 'корпуса' (назвать это просто 'микросхемой' язык не поворачивается) увеличится почти пропорционально. Давайте снова обратимся к "ONFI 2 Source-Synchronous Interface Breaks the I/O Bottleneck", страница 21.
Напоминаю, что 'Die' и LUN одно и то же, а 'Channels' следует понимать буквально - количество каналов (или корпусов микросхем на независимых шинах данных).
В таблице даны результаты для одного-двух-четырех LUN. Последний вариант, с четырьмя LUN встречается редко, поэтому прошу интерпретировать последний столбец как вариант установки двух корпусов. С точки зрения логики работы устройства, абсолютно неважно, будет ли использоваться один корпус с четырьмя target или два корпуса с двумя target. Просто будет заниматься больше или меньше места на печатной плате, а программное обеспечение контроллера SSD не заметит никакой особой разницы.
Обычно контроллеры, обслуживающие высокоскоростные NAND, поддерживают 4 (и больше) CE на один канал (4 target).
Пожалуйста, учтите важный момент - в презентации Micron использован классический, асинхронный режим LUN, что ограничивает скорость чтения. На запись такое замедление практически не оказывает влияния, ведь не оно ограничивает производительность (а время записи страницы).
Но, кому сейчас интересен асинхронный режим? Кто позволит себе 'просто так' потерять две трети производительности чтения? Так что, переходим к странице 21 и начинает очередную медитацию.
Начнем с режима чтения:
|
1 LUN. Мбайт/сек |
2 LUN. Мбайт/сек |
4 LUN. Мбайт/сек |
8 LUN. Мбайт/сек |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Если внешним интерфейсом устройства будет SATA 2 (максимальная производительность 250 Мбайт/сек), то вряд ли рационально применение больше двух каналов и общего числа LUN больше четырех.
Теперь о записи:
|
1 LUN. Мбайт/сек |
2 LUN. Мбайт/сек |
4 LUN. Мбайт/сек |
8 LUN. Мбайт/сек |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
А вот для записи зависимость линейная – чем больше LUN, тем лучше результат, без каких-либо признаков насыщения.
Для SSD, эмулирующей SATA 2 с ее ограничением в 250 Мбайт/сек, скорости выше озвученных 250 Мбайт/сек лишены смысла. Иначе говоря, для режима 'чтение' вполне достаточно контроллера с двумя каналами, с парой LUN на каждом. Много или мало 2 LUN? Вообще-то, это один корпус. Иначе говоря, для обеспечения очень высокой скорости чтения достаточно поставить всего две микросхемы. Очень даже бюджетное решение.
С записью сложнее, для MLC это тяжелый процесс и требует более мощной конфигурации.
реклама
Если у SLC скорость записи в 224 Мбайт/сек с достигается при двух каналах и четырех LUN на каждом, то MLC получение похожей производительности потребует уже 6-8 каналов * 8 LUN.
Восемь LUN это много? Для современных микросхем - да. Хотя стандарт и поддерживает четыре CE, что означает максимум восемь LUN (по два на CE), но такие микросхемы пока не особо распространены. Даже вариант два CE * два LUN почему-то не ставят в SSD. Что же, приходится эти '8 LUN' набирать большим количеством микросхем (и каналов, если используются микросхемы с одним LUN на CE).
Современные тенденции развития электроники направлены на миниатюризацию, поэтому следует ожидать плавного перехода на 4-8 LUN микросхемы, что обеспечит компактность и снижение стоимости, ведь отпадет необходимость в 5-8-канальных контроллерах.
SSD
Ну хорошо, технология NAND может обеспечить высокую скорость чтения и сносную - записи, но ведь это еще не весь SSD. Для работы устройства необходим достаточно высокопроизводительный контроллер и "какие-то" алгоритмы его работы по обслуживанию среды хранения информации (NAND) и ее передачи в систему (SATA или PCI-Express). "Какой-то" заключено в кавычки по банальнейшей причине - если по аппаратуре ходят слухи, то по алгоритмам и их нет. Что ж, будем делать безосновательные предположения и безапелляционные выводы, они сами напросились.
Несколько представителей породы высокоскоростных NAND
Возьмем то, что подвернется под руку.
Intel 29F64G08CAMD1-17
- 8 Гбайт
- 2 Die
- 2 CE
- common
Это означает, что на один target приходится один LUN. Признаки наличия плоскостей и синхронного режима отсутствуют.
Интересна маркировка скоростного режима '-17'. Стандарт ONFI декларирует для асинхронных режимов 4 и 5 время 25 нсек и 20 нсек соответственно. Более скоростного асинхронного режима нет, но если бы он все же был, то 17 нсек смотрелось бы очень к месту. Если же брать синхронные режимы, то близкими по значению могли бы быть Mode 2 (20 нсек) и Mode 3 (15 нсек). Нет, совсем не похоже.
' common' – выводы всех target объединены.
Micron MT29F32G08CBABBWP
- 4 Гбайт
- 1 Die
- 1 CE
- common
Скучно, всего один LUN.
Micron MT29F64G08CFABAWP
- 8 Гбайт
- 2 Die
- 2 CE
- common
Две target, на каждом один LUN.
Операции ввода-вывода
Стоит сразу уточнить, интересует не выполнение какой-то конкретной операции, а методика взаимодействия массива LUN с контроллером. Повторюсь, лично я точной информацией по данному вопросу не располагаю и, извините, все сказанное будет измышлизмом, что делает предположения весьма условными. Данные лежат страницами в LUN, но - как конкретно? Вариантов исполнения множество и, по счастью, они все базируются на принципе чередования. Но и здесь не всё просто - чередование может осуществляться на разных уровнях и соответствовать разной гранулярности - байт-чередование, блок-чередование, страница-чередование, плоскость-.... и вообще без чередования. А что, так же проще всего.
Ближайшую аналогию происходящего можно сопоставить с технологиями массивов RAID 0, когда два (несколько) диска могут выполнять операции с одним и тем же файлом одновременно, что повышает общую производительность. В SSD множество LUN и этот путь развития возможен, но здесь выходит на первый план такой параметр, как размер Stripe (величина блока чередования). В RAID 0 при обмене информацией, меньший Stripe, работает только один из накопителей. Впрочем, не все могут детально знать механизм работы RAID 0, поэтому очень кратко - в данной организации несколько дисков (положим, два) подключаются к контроллеру, который представляет их как один диск большей емкости. Ни первый, ни второй физический диск в системе не видны, их нет - вместо них система видит 'нечто' удвоенной емкости.
При записи контроллер рассыпает запросы чтения/записи на оба диска, которые выполняют их независимо, то есть одновременно. Например, при Stripe = 32 Кб и системном запросе чтения файла 64 Кбайт сам контроллер отправит по одному запросу чтения 32 Кбайт в диск номер один и номер два. При этом первые 32 Кбайт контроллер получит через то же время (с той же производительностью), что и в режиме без RAID 0, зато вторые 32 Кбайт будут для него 'бесплатными'.
Иначе говоря, система получит данные быстрее только по оценке времени 'среднее', если же оценивать мгновенную скорость поступления данных, то это может быть даже медленнее режима без RAID из-за дополнительных временных расходов на обслуживание контроллера и сегментирование обмена от небольшого размера Stripe. Сюда же стоит добавить возросшую загрузку процессора на гораздо бо́льшую активность операций ввода-вывода, ведь простые встраиваемые контроллеры RAID 0 не соединяют блоки Stripe и чтение большого блока данных рассыпается на множество запросов с размером Stripe. Увы, но объединения нет. Поэтому, для оптимизации Stripe была создана программа HAB. Я буду еще ссылаться на эту программу, но пока давайте завершим микрообзор RAID 0, сейчас это не самое интересное.
Чтение
Слегка упростим себе жизнь и рассмотрим режим однопоточный работы, без каких-либо вариаций NCQ. В режиме 'простой' для устройств подобного типа происходит весьма энергичная деятельность ... но давайте и здесь пока считать, что в режиме простоя контроллер спит.
Итак, контроллер спит (так или иначе, но любой контроллер в простое переходит в IDLE режим разной степени), и тут совершенное неожиданно приходит запрос на чтение последовательной группы секторов 4 Кбайт.
Первое, что он сделает, это отправит запрос в нужный LUN на чтение самого первого сектора, тут без вариантов. Но что будет происходить сразу после этого - как считывать следующие сектора так, чтобы не упала общая скорость?
Какие вообще можно применить методы расщепления для повышения производительности:
1. Байт-чередование.
Название условное и означает, что сектор данных равномерно распределяется между несколькими страницами NAND. Условность в размере чередования, вряд ли разумно распределять по байту в странице, ведь для получения сектора данных (512 байт) требуется считать одновременно 512 страниц NAND. Обращаю внимание на то, что при записи будет еще бо́льшая проблема. Все же, пока забудем о ней и рассмотрим, что данный прием может принести.
Понятно, что ‘байт’-чередование довольно глупо, скорее надо говорить о ‘строка-чередование’, скажем 512 байт. (Почему это число? Мммм - смотрит на потолок - скажем.)
Для получения обычного сектора в 4 Кб потребуется считать 4096/512=8 страниц.
Прелесть данного решения в том, что при чтении можно получить данные быстрее, чем будет считана одна страница NAND. Как было показано ранее, скорость считывания страницы около 27 Мбайт/сек или примерно 75 мксек. Если нужная информация находится в начале страницы, то для получения данных потребуется пропорционально меньшее время. С учетом задержек на выдачу команд, адреса и ожидания готовности это будет меньше, конечно, хоть и не в 8 раз.
Впрочем, вряд ли система будет позднее вычитывать данные, которые были на странице, но в ранних адресах, поэтому условие "если нужная" в предложении можно опустить.
Проблема возникнет при попытке записи по такой технологии. "These MLC NAND Flash devices do not support partial-page programming operations". Хороший подарок. Не то, чтобы непреодолимая проблема, но она есть. Вернемся к ней в разделе 'Запись'.
2. Страница-чередование.
Данный вариант мало отличается от предыдущего, кроме одного - размер блока чередования равен размеру страницы NAND, который обычно составляет 2 или 4 Кбайт.
При чтении первые данные будут получены через 75 мкс, последующие через меньшие промежутки времени из-за конвейеризации запросов буферизированного чтения.
3. Блок-чередование.
Если есть вероятность использования чередования маленькими блоками, то почему надо исключать чередование блоками, превышающими размер страницы или 4 Кб, (вроде бы) любимой операционными системами Windows? Блок стирания в NAND порядка 256-512 Кб. А что, даже в современных 'внешних', не встроенных, контроллерах RAID(0) используются близкие к такой величине рекомендации по выбору Stripe. Первая же мысль, которая закрадывается после прочтения данного предположения - ну это же бред. Просто так терять производительность - глупость полнейшая!
Однако позволю себе наглость обратить ваше внимание, что отдельные типы SSD существенно, буквально 'в разы', ускоряются при множественном режиме чтения (многопоточный доступ, AHCI). Это как раз и происходило бы при очень большом блоке чередования.
4. Без чередования.
По функциональности и внешним проявлениям очень напоминает режим 'страница-чередование', описанный выше. При этом будут выполняться практически такие же действия по считыванию и сохранению. Единственное отличие – размер доступа, когда переписывается весь блок, будет соответствовать размеру страницы. При наличии чередования эта величина в два раза больше. Впрочем, SSD обязан нормально работать с блоками 512 байт, что меньше размера страницы, поэтому возросший размер блока из-за чередования не существенен.
Запись
Если для носителей информации типа HDD нет особой принципиальной разницы в операциях ‘чтения’ и ‘записи’, то с SSD всё гораздо неприятнее. Здесь присутствуют два, даже скорее три, неприятных фактора - записывать можно только в стертую страницу и только ее целиком, стирается только куча страниц сразу (блок), да и сами процессы стирания и записи деструктивны - растет дефектность в градациях уровней ячеек, что снижает надежность хранения информации. Количество циклов MLC ячеек весьма невелико и составляет всего несколько тысяч циклов.
По технологиям SSD ходят только слухи, но все они совпадают в двух тезисах:
При добавлении данных они пишутся в массив свободных страниц.
Для ассоциации логического номера сектора и действительного места на NAND используется транслятор - таблица соответствия.
Иначе говоря, при поступлении измененных данных контроллер будет записывать не туда (не по тому адресу), где они располагались ранее, а в пул свободных страниц. Если вы десять раз переписали один и тот же файл, то, на самом деле, контроллер записал этот файл десять раз в свободное место на диске, каждый раз корректируя транслятор так, чтобы по логическим адресам 'снаружи' SSD читалась последняя копия файла. Такой нехитрый прием позволяет снизить вероятность неравномерной выработки NAND.
Итак, продолжим гадание, оно становится всё интереснее и интереснее.
У любого нормального контроллера SSD есть большая буферная память для временного хранения считанных данных и того, что надо (бы) записать. При получении данных на запись контроллер не станет сразу начинать процедуру записи в накопительную матрицу NAND. Все хитрее - контроллер будет стараться собрать последовательные запросы в блоки. По мере заполнения буферной памяти контроллер должен выбирать запросы с соседними адресами и отправлять их на запись. Попутно, он должен стирать неиспользуемые блоки NAND, и это важный момент, но пока опустим.
Итак, надо записывать. Тип чередования может различаться, но общая идеология сохраняется неизменной - надо записать несколько страниц данных, причем в разные LUN. Наверно, у Вас сразу возник вопрос - почему же обязательно 'в разные'? Да очень просто - нельзя организовать параллельное чтение из одного LUN! Конечно, в одном LUN есть две плоскости, но - смотрите числа, приведенные выше на презентации Micron - прям уж "в два раза" применение двух плоскостей не дает. Гм, может, поэтому у микросхем NAND фирмы Intel нет разделения на плоскости? Впрочем, не суть.
Иначе говоря, для получения высокой скорости чтения, именно чтения, надо записывать в разные LUN. Скорость записи и метод разбивки по LUN здесь не столь и важен, ведь сама запись выполняется в 'невидимом' режиме из-за применения буферизации в контроллере SSD, да и сами скорости записи существенно ниже требуемых скоростей чтения (из-за особенности работы NAND).
Итак, порядок записи в разные LUN выбирается из удобства чтения. Если в контроллере пять каналов, то записывать хорошо бы сразу во все пять микросхем (что означает 5*n LUN) - при чтении получится максимальное быстродействие. Но, простите, если занять все каналы, то до окончания процедуры записи страницы =все= LUN будут заняты и ничего считать не удастся. SSD буквально ‘отключится’. Напоминаю - процедура записи долгая, особенно если перед ней было вызвано стирание - оно-то выполняется еще дольше. Умный контроллер будет чередовать занятость каналов и количество страниц в единовременной процедуре записи. С точки зрения работы устройства последовательность и место расположения данных не важно́ - есть же транслятор, он переставит адреса.
Отметим первый вывод - когда контроллер выполняет массовые операции чтения и записи, разбивка данных по LUN может быть не оптимальной - часть данных одного файла могут попасть в один и тот же LUN. При чтении это 'свалит' параллельность считывания и произойдет падение производительности. Чем больше количества LUN в SSD, тем выше общая производительность записи и тем меньше коллизий попадания в один LUN. Сама процедура записи выполняется гораздо дольше, чем передаются данные для нее, поэтому на один канал можно поместить множество микросхем, и все они будут работать (записывать) практически одновременно.
Наверно, стоит задаться и сопутствующим вопросом - каналы контроллера обязательно синхронны? То есть все каналы полностью одновременно выполняют все операции? Думаю, вы согласитесь, что такой режим работы лишен смысла - не бывает настолько параллельных операций, чтоб все пять каналов могли сейчас записывать, а потом все пять считывать данные, затем все разом переключаются в режим стирания и так далее.
Понятно, что контроллер обычно много читает и иногда записывает, и может записывать пятью каналами ... но не всегда же. Это означает, что при жесткой фиксации произойдет падение производительности от недоиспользования каналов, часть из них будет простаивать. Это предполагает использование контроллером асинхронного режима работы каналов, когда операции на одном из них никак не зависят от загрузки других.
Например, у контроллеров памяти AMD есть два режима работы - синхронный и асинхронный. Если брать 'случайную' программу, без четкого детерминирования, то асинхронный режим немного выигрывает. С NAND эффект должен быть выражен еще ярче. Нас этот момент интересует только в том плане, что процедура 'контроллер начал запись' превращается в 'контроллер ищет свободные каналы и записывает', что также увеличивает риск записи данных в один и тот же LUN.
Свободное место
Очень интересно формируется емкость диска. Для HDD, в виду непревзойденной жадности производителей, емкость считается не в Мбайт, Гбайт или Тбайт, а по степеням десятки.
Общепринятая терминология по отношению к емкости (в байтах) компьютерных величин К-М-Г-Т означает:
К = 2^10=1024
М = К * К = 2^20 = 1024 К = 1048576
Г = М * К = 2^30 = 1024 М = 1073741824
Т = Г * К = 2^40 = 1024 Г = 1099511627776
Если вы где-то увидите надпись "2 Кбайт", то это не может прочитаться иначе, чем 2*1024=2048 байт. Но это мы не можем, а производители дисков могут всё.
На диске написано 1 Тбайт, и думаете, там 1 Тбайт? Отнюдь, там 1000,000,000,000 байт. Разница этого 'лукавства' составляет 1. 0995 раза или около 100 Гбайт. Поставили диск, отформатировали и получили 0.9 Тбайт.
Извините, обращу внимание, это действительно важно! Некоторые тесты возвращают цифры быстродействия в те же "кукурузных" (десятичных) байтах. Запускаешь тест USB Flash, видишь скорость записи 28 Мбайт/сек, что 'со скрипом' проходит декларированные производителем, а потом реальная работа с таким накопителем оказывается не лучше 26 Мбайт/сек. Начинаешь искать ошибку, перестанавливать .... (ну, думаю, всем знакомо) ... а потом читаешь маленькими буквами - скорость указана для 100000...000 байт/секунду. Ну не знаю, кому может доставить удовольствие такая 'мелочь'.
Ну ладно, к нашим баранам. Если с HDD всё ясно, на них можно нарезать сколько угодно данных без четкой привязки к размерности, то в SSD всё иначе - емкость накопительного элемента NAND всегда кратна два в степени n! (с TLC несколько не так, но нам сильно везет – пока их не используют в SSD).
Бытует мнение, что производители прячут часть памяти для отбраковки сбойных страниц. Да, под некондицию надо резервировать место, но не думаю, чтоб столько. У SSD появился транслятор, под него тоже уходит место, как и под различные служебные структуры счетчиков использования, хотя последние могут сохраняться в зоне ECC страницы. 'Исчезает' существенный объем накопителя, но не так же много.
Но это не всё, по мере забивания SSD данными его скорость падает. Рекомендуется оставлять свободной не менее 1/4 емкости SSD (и это при его сумасшедшей цене за Мбайт), а лучше половину (!) диска. Иначе может наступить деградация свойств. Вы привыкли всё свалить на HDD и забыть? С SSD такое не пройдет. Свалили на него ненужный хлам - оставили мало места - SSD упадет в 'я никакой'.
Что за феномен, и как оно лечится?? Четкого ответа нет, можно только предполагать.
Запись информации производится в пул чистых страниц, но чем меньше свободного места, тем меньше сам пул и чаще приходится перетрясывать систему для поиска незанятых страниц и их группировки к последующей очистке (стереть можно только блок страниц). Как хорошо, если диск полупустой - пришла команда записи, пихнул команды в нужные LUN и дальше, на фоновом процессе, неторопливо ищешь ненужное и потихоньку стираешь. Когда свободной памяти нет, то придется писать 'что уж есть' и 'куда уж есть'. Тут уж данные раскидываются а-бы-как, и об оптимизации чтения приходится просто забыть.
Кроме того, я с ужасом думаю про транслятор. Есть вероятность, что он начинает принимать сложную древовидную структуру, что также увеличивает затраты на чтение из-за трудностей с получением целевого списка страниц. Конечно, всё зависит от конкретной реализации программного обеспечения SSD, но проблема общая.
Для нормализации работы SSD применяются программные надстройки между операционной системой и диском – TRIM (информация о незанятых секторах файловой системы) и Garbage Collection (сборка мусора). Об этих технологиях сказано много, поэтому специально останавливаться на них не стоит. Суть их примерно одинакова - объяснить SSD, где что и как ему надо вычистить в своей матрице для освобождения монотонного (непрерывного) пула страниц. И чем меньше свободного места на диске, тем чаще придется выполнять чистку, да и сама чистка будет не слишком 'чистой'.
Да, у SSD свои болячки, Вы не знали?
Так что, я не склонен считать 'жадностью' производителей то, что они прячут часть емкости SSD. Она не пропадет, ведь смысл ее использования весьма прозрачен и прямо сказывается на производительности и времени работы SSD. Ведь, чем чаще 'перетрясывается' SSD для упорядочения страниц и выравнивания нагрузки, тем больше записи производится.
реклама
Лента материалов раздела
Соблюдение Правил конференции строго обязательно!
Флуд, флейм и оффтоп преследуются по всей строгости закона!
Комментарии, содержащие оскорбления, нецензурные выражения (в т.ч. замаскированный мат), экстремистские высказывания, рекламу и спам, удаляются независимо от содержимого, а к их авторам могут применяться меры вплоть до запрета написания комментариев и, в случае написания комментария через социальные сети, жалобы в администрацию данной сети.
Комментарии Правила