Некоторое время назад ко мне обратился мой хороший знакомый с просьбой помочь подцепить к его компьютеру SSD. Не считаю себя крупным специалистом в этом деле, но у него нужных знаний и навыков еще меньше, чем у меня, поэтому он и обратился. И суть обращения была в том, что в BIOS’е своей системной платы он не нашел, как включить режим AHCI контроллера SATA. Он попробовал обновить BIOS системной платы (она примерно 10-летней давности, P5G41T от ASUS) – но это не помогло. А по имеющемуся у него пониманию, SSD без перевода контроллера SATA в режим AHCI нормально функционировать не сможет.
Я тоже хорошо помнил рекомендации из статей, которые мной были прочитаны лет пять назад, когда я знакомился с SSD: вначале нужно войти в BIOS и включить AHCI, выключить компьютер, и только после этого подключать шлейфы к SSD. Примерно так было написано почти в каждой второй из прочитанных мной статей, я проглядел их тогда с полдюжины. Но на моей системной плате в BIOS’е этот режим был, я его включил, и больше не вникал в подробности работы накопителя, лишь проверил, что TRIM работает (это было второе важное знание, вынесенное мной из чтения тех статей). Ну и все. А что будет, если попробовать подцепить SSD к материнке без активации режима AHCI, я не задумывался, вроде как было незачем. Сейчас пришлось задуматься.
Я попробовал найти вариант решения проблемы в Интернете. Но каких-либо рекомендаций, кроме выкинуть плату и купить новую, найти не удалось. Зато нашёл статью “Можно ли эффективно использовать SSD без поддержки TRIM?”, опубликованную в далеком 2015-м году. Она не про AHCI, но она заставила задуматься над, казалось бы, азбучными истинами.
Вот, например, всеобщая рекомендация обязательно включить AHCI перед использованием SSD. А если этого не сделать? Ведь в явном виде никто из авторов статей, о которых я упомянул, не сказал, что SSD без AHCI работать не будет. Но рекомендации обязательно включить этот режим перед установкой SSD неявно заставили нас поверить в то, что нет, не будет работать. Иначе зачем упирать на обязательность? Согласны?
Здесь уместно задаться вопросом – а для чего при работе с SSD нужен режим AHCI? Вот здесь, например, описано, что из себя представляет режим AHCI:
“AHCI — режим работы современного накопителя, предоставляющий расширенный функционал … В первую очередь — возможность «горячей» замены жестких дисков. … Во-вторых, наличие реализованного алгоритма аппаратной установки очередности команд (NCQ), существенно ускоряющей работу накопителя и производительность системы в целом. Это достигается за счет грамотного и оптимального алгоритма движения считывающей головки по блину классического HDD или более эффективного использования ячеек памяти в случае SSD накопителя.”
Нечто аналогичное, но в более заумной форме, можно найти и в википедии.
Иными словами, во-первых этот режим нужен для “горячей замены” HDD или SSD, которая обычному пользователю, когда он трезв, не нужна. А во-вторых – оптимизируется считывание данных с жестких дисков. Работа обычного HDD ускоряется на 15-20% за счет более рационального размещения блоков на диске. Для SSD подобная оптимизация вряд ли ускорит его работу более чем на единицы процентов, т.к. скорость обращения к различным ячейкам памяти в пределах модуля практически неизменна. Так что, вроде бы, этот режим не столь уж и нужен нам.
Подумав об этом, я вспомнил кое-где проскочившие рекомендации, как включить режим AHCI, если он не был включен перед установкой Windows 7 или Windows 10. То есть, если объясняют, как включить ранее не включенный режим AHCI путем некоторых манипуляций в работающей ОС, то это однозначно означает, что SSD не только может работать без AHCI, но и позволяет без него установить операционку. Иначе было бы сказано, что сносите всё, что вы установили без AHCI, и ставьте по-новой. А здесь – рекомендации по поствключению этого режима, со ссылкой на Microsoft. То есть, скорее всего SSD без AHCI будет работать, но это надо проверить экспериментально.
У моего знакомого SSD еще не было, он не рискнул его покупать, не будучи уверенным, что все заработает. У меня же был свободный на тот момент SSD, приобретенный впрок на АлиЭкспресс, и поэтому мы смогли проверить, увидит ли системная плата этот накопитель, и сможем ли мы поставить на него операционную систему. Эксперимент показал, что BIOS платы понимает SSD, подключенный к разъему SATA (фото 1).
Далее на этот SSD была установлена “десятка”, она встала совершенно штатно. Без какого-либо режима AHCI.
Следующим встал вопрос – а команда TRIM без режима AHCI будет работать? Однозначного ответа на этот вопрос в сети мы не нашли. Поэтому также проверяли это экспериментально. В одной из статей в сети мы наткнулись на упоминание об утилитке TRIMcheck, с помощью которой проверить работу TRIM очень просто. (Примечание: утилита не сработает, если диск сжат, т.е. установлен соответствующий флажок в свойствах диска).
Утилита запускается с того SSD-диска, который мы хотим проверить. Вкратце, принцип работы утилиты таков:
- При запуске утилита записывает данные на диск и отмечает адреса виртуальных блоков, в которых они размещены. Эти адреса она сохраняет в JSON-файл в своей папке, после чего удаляет данные, что порождает отправку команды TRIM (если она включена).
- При повторном запуске утилита смотрит, находятся ли записанные ранее данные по сохраненным адресам. Их отсутствие означает, что TRIM запущена, контроллер принял команды TRIM к сведению и удалил данные.
Рекомендуется следующая последовательность работы с TRIMcheck:
- Запустите утилиту с диска, на котором хотите проверить работу TRIM, и нажмите Enter.
- Закройте окно, подождите пару минут и повторно запустите утилиту.
На фото 2 показано сообщение, подтверждающее работу TRIM в “десятке” (CONCLUSION: TRIM appears to be WORKING!).
В литературе указано, что TRIM запускается в операционных системах Windows 7 и старше, в ХР не запускается. Хотя я наткнулся на рекомендации, как ее запустить в ХР (через программу O&O Defrag). Ради интереса, я установил на этот же SSD в этой же материнской плате Windows XP, и попытался запустить TRIM рекомендованным образом. После этого я запустил TRIMcheck. Увы, как видно из фото 3, чуда не произошло. В ХР TRIM, в отличие от “десятки”, не заработал (CONCLUSION: TRIM appears to be NOT WORKING).
Итак, вывод первый – включение режима AHCI (если он поддерживается материнской платой) вовсе не является обязательным при работе с SSD. Хотите включайте его, хотите - нет. Если он не поддерживается – не заморачивайтесь его отсутствием, главное – чтобы BIOS системной платы определял этот SSD (речь идет о случае корректной работы контроллера SATA на материнской плате. А вот при некорректной работе – как получится, жесткий диск может с AHCI работать, а без него – нет, а может быть и наоборот).
Второй вывод – команда TRIM запускается операционной системой вне зависимости, включен ли режим AHCI, или контроллер работает в стандартном режиме SATA. Причем запускается автоматически (опять же, если нет конфликтов в ПО или в “железе”).
Но самый интересный вопрос – а так ли необходима для SSD-накопителя команда TRIM? Или это очередной маркетинговый ход Microsoft?
В уже упомянутой “Можно ли эффективно использовать SSDбез поддержки TRIM?” автор пишет, что “ … большинство серверных конфигураций дисковой подсистемы TRIM не поддерживают, либо поддерживают, но в очень ограниченном объеме. При этом некоторую странность вызывает то, что ни производители железа, ни производители софта не спешат с этой "проблемой" что-либо делать.”
Чтобы понять, в чем дело, давайте вспомним, как воспринимают диск разные подсистемы ПК, участвующие в работе с ним. Программы и ОС взаимодействуют с файловой системой (ФС), работая на уровне кластеров и таблицы файлов. О том, что находится ниже, ОС не имеет никакого представления. ФС воспринимает диск как некоторое блочное устройство стандартного формата, также не сильно вникая в его внутреннюю суть, отдавая все вопросы на откуп драйверу контроллера запоминающих устройств. Тот, в свою очередь, воспринимает диск как некоторое LBA-устройство, не зная его внутренней структуры. О том, как именно конфигурация LBA соответствует физической конфигурации устройства знает только контроллер диска. А он, в свою очередь, не имеет ни малейшего представления о файлах, разделах, кластерах и т.п.
Физически пространство SSD делится на страницы, которые являются минимально адресуемым участком памяти. Для того, чтобы изменить ячейку памяти, необходимо считать страницу, изменить в ней необходимые данные и записать ее на прежнее место. Здесь возникает первая сложность: в отличие от HDD, в SSD писать можно только в заранее очищенные ячейки. При этом технически очистить отдельную страницу нельзя, очистке подвергаются только группы страниц, объединяемые в блоки.
Размеры страниц и блоков зависят от конфигурации памяти конкретного SSD, типичными являются значения 4 КБ для страницы и 512 КБ для блока. А теперь представим, что мы открыли файл и изменили в нем 100 байт данных. Для HDD проблемы нет, он считает нужный сектор (512 байт), изменит данные и перезапишет его. В реальности будет все чуть-чуть иначе, но никаких дополнительных накладных расходов это не повлечет.
А вот SSD не может взять и просто так записать измененные данные. Для этого ему потребуется считать куда-то весь блок, произвести требуемые изменения данных, очистить ячейки, в которых находились данные этого блока до изменения, и вернуть все данные назад. Поэтому вместо изменения и записи 4 КБ данных SSD придется перезаписать 512 КБ данных. Это, во-первых, не самым лучшим образом скажется на ресурсе ячеек. А во-вторых, операция стирания ячеек достаточно медленная в сравнении с записью в чистые ячейки, и именно необходимостью стирания перед записью объясняется снижение быстродействия SSD.
Чтобы решить эту проблему, в SSD применяется алгоритм "копирование при записи": при необходимости перезаписи данных на уже существующей страницы, она после перезаписи копируется в свободные ячейки в другое место, а ячейки, где она находилась, помечаются как доступные к очистке.
Это позволяет SSD сразу записывать измененные данные, не вызывая при каждой перезаписи процедуру очистки. Так будет продолжаться до тех пор, пока не кончатся свободные ячейки.
Несложно заметить, что через некоторое время на диске вперемешку окажутся свободные, занятые и доступные к очистке страницы. Здесь вступает в действие алгоритм внутренней оптимизации, именуемый "сборкой мусора". Он перемещает данные на SSD таким образом, чтобы сгруппировать доступные к очистке страницы в отдельные блоки и очистить их.
Именно от эффективности данного механизма зависит, как долго диск сможет поддерживать высокую производительность при интенсивной записи на него. Основное условие высокой скорости работы с SSD (в первую очередь – записи) - это наличие свободных ячеек. Эффективность алгоритма уборки мусора отвечает за то, как быстро доступные к очистке ячейки будут становиться свободными.
Из-за чего наступает “торможение” SSD? Из-за того, что свободные ячейки кончаются, например, мы полностью заполнили пространство диска. В этом случае, правда, у SSD все равно остается пространство для маневра в виде резервной области, которая предназначена для замены вышедших из строя ячеек, но достаточного количества свободных страниц может не оказаться и там.
Если размер резервной области небольшой, а интенсивность записи высокая, то сборщик мусора будет не успевать эффективно очищать блоки, и мы получим упомянутое “торможение”.
Заметьте, мы до сих пор ни словом не обмолвились о команде TRIM. А она для чего нужна, как она помогает избежать “торможения” работы SSD при отсутствии свободных ячеек для перезаписи?
Здесь нужно вспомнить, что удаление файла в современных файловых системах физически не происходит, удаляется только запись в таблице файлов, после чего данное место считается свободным. При этом сами данные будут оставаться на диске до тех пор, пока в ячейки с ними не будет осуществлена запись нового файла. То есть, до момента этой перезаписи в ячейках хранится уже ненужная информация. А файловая система никак не сообщает контроллеру SSD о таких данных, и он продолжает считать эти ячейки занятыми. При полном заполнении всех ячеек накопителя и последующем стирании части этих ячеек (удалении части записанных файлов) контроллер будет воспринимать ситуацию так, будто диск полностью заполнен, хотя с точки зрения ФС там много свободного места и она будет пытаться писать туда, откуда удалены файлы..
В этом случае SSD будет полностью считывать блок в память, очищать его и заново записывать измененные данные. Но свободных ячеек у него не прибавиться, будет только то, что есть в резервной области.
А как же технология сборки мусора? А никак, будет простаивать. Потому что убирать ей нечего. Эти ячейки свободны только с точки зрения файловой системы, с точки зрения контроллера диска в них записаны данные. Понять, что эту страницу нужно очищать, диск сможет только тогда, когда система попытается туда что-либо записать.
Для того, чтобы файловая система сообщила контроллеру, что эти данные удалены, и придумали команду TRIM. Её задача - пометить страницы с удаленными данными как доступные к очистке, а дальше в дело вступит все тот же сборщик мусора.
Таким образом команда TRIM никак не поднимает производительность SSD: если вы заполнили диск практически полностью, а резервная область невелика, то получите резкое снижение производительности SSD, что с TRIM, что без неё. Даже если вы после этого удалите файлы и принудительно пошлете команду TRIM - производительность будет оставаться низкой до тех пор, пока сборщик мусора не очистит достаточно свободных ячеек. Именно поэтому желательно, чтобы TRIM сообщала контроллеру об освобожденных файловой системой ячейках не тогда, когда контроллеру уже некуда перезаписывать данные, а гораздо раньше. Тогда сборщик мусора успеет подготовить контроллеру новую порцию чистых ячеек для перезаписи, и “торможения”, скорее всего, не произойдет.
Здесь самое время вспомнить про корпоративные серии SSD, которые зачастую не блещут производительностью, но зато предлагают высокую надежность и обеспечивают эффективную работу даже без поддержки TRIM. За счет чего это происходит? За счет бОльшего размера резервной области. Это позволяет всегда иметь достаточный запас свободных ячеек и благотворно сказывается на эффективности работы сборщика мусора. Обычные SSD низшего ценового диапазона имеют размер резервной области в 6-7% от емкости диска, этого размера явно недостаточно для поддержания высокой производительности. Корпоративные диски имеют в 3-4 раза бОльший объем резервной области, что напрямую сказывается на их стоимости. Это позволяет им уменьшить износ каждой доступной пользователю ячейки и эффективно работать в RAID-массивах без поддержки TRIM.
А что делать владельцам обычных или "корпоративных" бюджетных дисков? Ответ прост - обеспечить диск достаточным количеством свободных ячеек. Самый простой способ сделать это - разметить не всю доступную емкость диска. Как показывает практика - резерв в 20-25% емкости накопителя (но не более 80-100 Гб) позволяет эффективно использовать даже полностью заполненный диск без поддержки команды TRIM.
На фото 4 приведена такая разметка 512-гигабайтного пользовательского SSD. 100 Гб в конце диска оставлены неразмеченными, ФС их не сможет занять какими-либо файлами. Благодаря этому контроллер имеет 120-130 гигабайт ячеек в своем распоряжении, недоступные “шаловливым ручонкам” ФС. По литературным данным, 25%-я резервная область вполне достаточна для уверенной работы SSD без “торможения” без команды TRIM, даже тогда, когда все размеченное пространство накопителя будет заполнено ФС.
Нужно только отметить, что неразмеченный кусок должен быть создан сразу после установки ОС, т.е. гарантировано до того, как она, обслуживая установленные программы и игры, запишет туда какую-то информацию. И, конечно, если диск ранее использовался, то перед установкой ОС он должен быть отформатирован в режиме полного (не быстрого) форматирования, иначе неразмеченная область не будет гарантированно свободной от ненужных данных.
Если статья понравилась, не забывайте ставить лайки. Ибо политика Дзена такова, что материал с малым количеством лайков и комментариев считается неинтересным для аудитории, и перестает попадать в ленту. Ставя лайк, вы увеличиваете вероятность того, что этот материал сможет прочесть еще кто-то.