Работает ли trim в raid
Когда сегодня заходит речь о производительности системы хранения обычно разговор сразу переходит на современные накопители SSD. При этом лидерами являются устройства с интерфейсом PCIe, способные обеспечить на последовательных операциях скорости на уровне нескольких гигабайт в секунду. Если же говорить о моделях с SATA, то здесь у быстрых устройств можно увидеть производительность до 600 МБ/с. На случайных операциях разница между этими классами тоже есть, но она уже менее заметна.
При этом продукты стандартного формата 2,5’’ с интерфейсом SATA имеют несколько преимуществ – они обычно дешевле, могут работать практически в любой системе нескольких последних поколений, из них удобно делать массивы для обеспечения большой емкости СХД (и/или повышения отказоустойчивости), их можно устанавливать в большом количестве в стандартные корпуса.
Использовать чипсетный RAID не очень интересно, так что в этот раз посмотрим, насколько хорошо аппаратные RAID-контроллеры могут работать в подобных конфигурациях. Заметим, что использованное оборудование преимущественно относится скорее к среднему массовому сегменту, чем к наиболее производительным продуктам. Все-таки на рынке уже есть контроллеры и накопители с интерфейсами SAS и PCIe, но это уже совсем другой ценовой уровень.
Выбранные условия тестирования, конфигурации и инструменты наверняка вызовут много вопросов, которые можно будет обсудить и наметить направления для следующих материалов. Все-таки подобные тестирования имеют слишком много вариантов и тонкостей настройки (в том числе и в зависимости от задач), что охватить их все в одной публикации просто невозможно.
Конфигурация тестовой системы была следующей:
материнская плата Asus Z87-A
процессор Intel Core i7-4770
32 ГБ оперативной памяти
отдельный SSD для операционной системы
В роли SSD-накопителей выступали четыре Samsung 850 EVO второго поколения по 1 ТБ. Отметим отдельно, что накопители перед этим отработали около семи месяцев в сервере с Linux и никогда не знали TRIM (и по время проведения данных тестов они этого тоже не узнали). При этом прошлая нагрузка была преимущественно на чтение. Объем проведенной записи не превышал двух емкостей диска. По всем параметрам накопители были в отличном состоянии.
Контроллеров удалось найти сразу пять – четыре модели от Adaptec/Microsemi и один от LSI/Broadcom (на фото попали не все):
Первый, конечно, уже морально устарел, однако по факту еще много где используется. Так что будет интересно посмотреть, насколько эффективно он сможет работать с новыми накопителями. Второй уже имеет 6 Гбит/с порты и работает на шине PCIe 3.0, так что вполне актуален. Третий представляет собой последнее поколение «классических» решений Adaptec и поддерживает 12 Гбит/с интерфейс для дисков SAS. Реализованную в данной модификации технологию maxCache в этой статье мы использовать не будем. SmartRAID был представлен в конце прошлого года и относится к актуальному поколению RAID-решений компании. К сожалению, он использует новую разметку и схему хранения конфигурации и поэтому не может быть использован для замены прошлых моделей с сохранением данных на дисковых томах. MegaRAID 9361-16i можно считать представителем актуальной линейки продуктов LSI для массивов с накопителями SATA и SAS.
SSD подключались через обычный бекплейн с раздельными каналами для каждого диска. От бекплейна к контроллеру шел один стандартный кабель SAS на четыре канала.
На контроллерах, если не указано обратное, были активированы кэши на чтение и на запись. Все контроллеры имели резервные батареи. Том создавался заново на каждом контроллере, хотя по факту серии 6-7-8 у Adaptec позволяют переносить его без потери данных «в любом направлении».
Поскольку мы ходим протестировать в основном контроллеры, то в качестве основной конфигурации для дискового массива был выбран RAID0 с блоком 256 КБ. При этом надо отметить, что подобное решение может быть использовано и на практике, когда хочется иметь относительно большой и быстрый массив на небольшие деньги. Конечно при условии, что есть резервные копии и время простоя не критично. Да и заявленные производителями цифры по надежности SSD все-таки внушают доверие.
В качестве тестового пакета выступал уже очень немолодой, но все еще пользующийся популярностью IOMeter. Прежде всего, отметим, что опций по выбору конфигураций как массива, так и собственно теста слишком много. С этой стороны это хорошо – вы можете подобрать их исходя из требований своих приложений. С другой – это делает бессмысленно долгим их перебор в рамках одной статьи. Так что были выбраны шесть вариантов шаблонов – три (чтение, запись, 50% чтения и 50% запись) на последовательные операции блоками по 256 КБ (совпадающим с размером блока массива) и три на случайные операции с блоками 4 КБ (наиболее часто используемый размер). В первой группе будем ориентироваться на МБ/с, во второй – на IOPS. Во время тестов использовался один worker, в настройках указывалось для Outstanding I/O значение 32. Тесты проводились на неразмеченном «сыром» томе.
BIOSы, драйвера и программное обеспечения для контроллеров использовались последний версий на момент проведения тестов.
Для начала посмотрим на результаты одного SSD, полученные на встроенном в материнскую плату контроллере.
Итак, один диск показывает скорость линейного чтения около 400 МБ/с и линейной записи около 160 МБ/с. На случайных операциях получается примерно 95 000 IOPS на чтении и 7 500 IOPS на записи. Для «использованных» устройств это, пожалуй, неплохие результаты. Напомним, что если оценивать современные жесткие диски, то можно рассчитывать примерно на 150-250 МБ/с на линейных операциях и 100-200 IOPS на случайных.
На следующих графиках представлены результаты тестирования массива со стандартными для дисковых массивов настройками контроллеров – когда для тома используется и кэш самого контроллера. Заметим, что при организации тома на SSD некоторые производители рекомендуют не использовать кэш контроллера для увеличения производительности и снижения задержек. Этот вариант мы рассмотрим далее.
Итак, на линейном чтении мы ожидаемо видим пропорциональный количеству дисков в массиве рост. Все контроллеры показывают около 1 600 МБ/с. А вот на записи и смешанной нагрузке уже можно что-то выбрать исходя из своих требований и возможностей. Даже немолодой Adaptec ASR-6805 смотрится не так уж и плохо в этом сценарии.
А вот случайные операции существенно меняют картину. Здесь уже играют роль возможности установленного на контроллерах процессора и можно увидеть существенные отличия. Старший контроллер Adaptec уже явный аутсайдер. Да и ASR-7805 тоже уже не может обеспечить существенного роста на случайном чтении и записи. Так что если важен именно такой сценарий — стоит смотреть на контроллеры последних поколений. Хотя и они способны только в два раза улучшить IOPS на чтении и записи при использовании четырех SSD. Отметим также, что на смешанной нагрузке заметно лучше других выступили Adaptec SmartRAID 3152-8i и LSI 9361-16i.
Посмотрим теперь, что будет если не использовать кэширование на контроллерах. Для модели Adaptec SmartRAID 3152-8i здесь используется специальный предусмотренный производителем режим SSD IO bypass.
На последовательных операциях чтения результаты мало отличаются от приведенных выше, что вполне ожидаемо. На записи контроллеры при отключении кэша ведут себя по разному и скорость может значительно меняться, так что стоит обратить внимание на тип нагрузки и подобрать оптимальный вариант
Еще более интересно выглядят цифры в сценарии случайных операций. Отключение кэша может существенно увеличить скорость доступа на чтении, но и в два раза снижает IOPS на операциях записи. Так что если не стоит задачи снижения времени отклика на большой нагрузке чтением, лучше оставить кэш включенным.
Заметим, что были протестированы только «крайние» варианты — включение кэшей и на чтение на запись и полное отключение кэширования. В реальности у контроллеров есть независимые настройки на чтение и запись, так что конфигураций можно получить больше. Учитывая, что параметры массива можно менять и «на лету» без потери данных, можно самостоятельно подобрать оптимальный для сценария применения вариант. Кроме того, и сами контроллеры могут иметь множество опций «тонкой настройки», которые стоит хотя бы быстро просмотреть.
Подведем итоги. «Бытовые» SATA SSD при работе с RAID-контроллерами чувствуют себя достаточно хорошо. Для раскрытия их возможностей желательно использовать контроллеры последних поколений, способные обеспечить высокие IOPS на случайных операциях. При этом существенное влияние на результаты оказывают настройки тома на контроллере и очень желательно подбирать их исходя из потребностей задач, поскольку «сделать хорошо» одновременно для всех сценариев невозможно.
В качестве бонуса — результаты тестирования конфигурации RAID5 на контроллере Adaptec ASR-7805 на том же оборудовании.
Эта проблема наиболее актуальна для аппаратных RAID или firmware RAID (таких как Intel RST RAID 1/10/5/6) с непромышленными SSD.
Особенность SSD
SSD пишут и читают данные страницами, записать можно только на очищенные страницы, а очистить страницы можно только большими блоками. Например, у диска размер страницы 8 КБ, в блоке находится 128 страниц, таким образом, размер блока — 1024 КБ (здесь и далее, если не указано иного, КБ и МБ двоичные).
Например, если изменить 40 КБ в одном файле, то на физическом уровне это будет выглядеть так:
На логическом уровне всё выглядит как обычно — данные будут перезаписаны поверх в соответствующих секторах. Как только в блоке 1 останутся исключительно пустые и готовые для очистки страницы, этот блок стирается и становится пустым целиком.
Чтобы скрыть физическую реализацию, диск поддерживает карту соответствия логических и физических номеров страниц (Flash Translation Layer).
Пока мы видим только один путь, которым физическая страница сможет стать снова очищенной — если на её логический адрес запишут новые данные. Дело в том, что контроллер диска работает на уровне страниц и не знает ничего о файловой системе, а операционная система никак не извещает диск об удалённых файлах, какие секторы могут быть очищены. Несложно видеть, что рано или поздно каждая страница диска будет занята и ему будет некуда писать данные.
Чтобы решить это проблему, была добавлена команда ATA TRIM (wiki). Операционная система посылает её диску с указанием секторов, которые могут быть очищены. Аналоги этой команды — SCSI UNMAP и CF ERASE. К сожалению, в некоторых случаях нет возможности послать её диску:
— если диск находится в RAID с аппаратным контроллером (LSI, Adaptec и т. п.),
— если диски находится в firmware-RAID, в частности, Intel RST RAID 1/10/5/6,
— если диск подключен по USB (ограничение протокола),
— если диск зашифрован программно через TrueCrypt, dm-crypt, GELI и т.п. (может поддерживаться, но обычно не включается по соображениям безопасности).
Если в результате тестирования выясняется, что диск не получает команду TRIM, то вскоре для записи может остаться совсем мало свободных страниц. Но они будут: каждый диск содержит некоторую зарезервированную область, которая служит как запас свободных страниц и запас блоков на замену полностью изношенным. Чтобы узнать размер этой области нужно посмотреть, какой физический объём памяти установлен на диске и сколько LBA указано в документации.
Например, Samsung SSD 840 Pro 512 GB имеет 512 ГБ памяти, при этом доступно 1000215216 LBA секторов. Резерв составляет: 512 × 1024 × 1024 × 1024 — 1000215216 × 512 = 35 ГБ или 6,85 %. Доступная ёмкость диска при этом составляет (512 — 35) × 1024 × 1024 × 1024 = 512 × 10^9 = 512 ГБ, уже десятичных. Samsung SSD 850 Pro 128 ГБ имеет на борту 129 ГБ, пользователю доступно 128 ГБ десятичных, резерв — 7,6 %.
Итак, если мы заполним весь диск, потом удалим все файлы, то без поддержки TRIM диск сможет писать только на какую-то часть от 6,85 % объёма диска. Часть, потому что этот резервный объём будет частично состоять из не полностью пустых блоков из-за фрагментации. Наличие этой области позволяет хоть как-то продолжать перезапись файлов на диске.
Пример худшей ситуации: писать некуда, хотя объём занятых страниц не превышает доступный пользователю без резерва.
В этом случае одновременно с записью работает сборщик мусора, который будет читать блок в оперативную память, стирать блок на диске (долгая операция, стирание занимает 3000 мкс в сравнении с 900 мкс записи в пустую страницу) и записывать блок из оперативной памяти. Задержка происходит также из-за роста Write Amplification — на одну логическую операцию записи приходится 5-10 физических операций записи.
Поэтому чем больше у диска есть свободного места для манёвров, тем выше скорость записи. Сборщик мусора в фоне занимается не только очисткой и дефрагментацией блоков, но и равномерным распределением циклов записи/очистки (P/E) по блокам, чтобы они изнашивались одинаково.
Есть популярный миф, что у современных дисков настолько хороший сборщик мусора, что им не нужен TRIM. Это совершенно не так, сборщик мусора и TRIM решают разные задачи.
Промышленные диски часто имеют 50% и больше резервной области, поэтому для них отсутствие TRIM не критично. Остальные диски чаще всего вообще не имеют явно заявленной резервной области, или она недостаточна. Тесты показывают, что хороший эффект имеет объём over-provisioning 25-29 % от общего объёма физической памяти (включая резервную область). Поэтому если у диска недостаточный объём резервной области, то нужно сделать over-provisioning самостоятельно.
Есть три способа:
— разметить диск таким образом, чтобы оставить некоторую часть неразмеченной области, после создания RAID,
— использовать команду ATA для создания Host protected area (howto), до создания RAID,
— настроить RAID контроллер, чтобы он использовал только часть объёма диска.
Прежде чем выделить свободную область, нужно дать знать диску, что эта область ничем не занята, одним из двух способов:
— подключить диск к другому контроллеру и послать команду ATA TRIM (или при помощи O&O Defrag — есть cli интерфейс, Windows 8 встроенный оптимизатор дисков или Anvil's Storage Utilities),
— сделать полную очистку таблицы FTL, послав команду ATA Secure Erase.
Есть версия, что также можно заставить диск понять, что блоки не используются, если туда записать 0x00 или 0xFF (так называемый метод «Tony TRIM»). Возможно, для каких-то контроллеров это работает, но мои тесты не показали изменений.
На практике
У меня есть два диска Samsung SSD 540 Pro 512 GB в Intel RST RAID 1, на которых установлена Windows 8.1. После года работы я измерил производительность и был неприятно удивлён. После проверки TRIM я увидел, что он не работает.
— Проверка TRIM под Windows,
— Проверка TRIM под Linux:
Колонки DISC-GRAN и DISC-MAX обе должны быть больше 0 для всех участвующих компонентов.
Альтернативный вариант:
После удаления файла на диске должны быть 0x00 или 0xFF, но это недостоверный способ: разные диски ведут себя по-разному.
TRIM в реальном времени включается опцией «discard» при монтировании диска:
TRIM для файловых систем на одиночных дисках и LVM поддерживается с ядра Linux 2.6.33. TRIM для mdraid поддерживается с ядра Linux 3.7. Но может быть портирован и на старые версии ядра, например, поддерживается в CentOS 6.
По-умолчанию Ubuntu делает TRIM по расписанию раз в неделю при помощи fstrim, но только для одиночных дисков (не mdraid) следующих производителей: Intel, Samsung, OCZ, SanDisk и Patriot и если установлен «hdparm».
— Проверка TRIM в FreeBSD:
ZFS по-умолчанию поддерживает TRIM начиная с версии FreeBSD 9.2:
GEOM RAID gmirror поддерживает TRIM с FreeBSD 9.1:
колонка «d/s» — BIO_DELETE/second.
Intel RST RAID поддерживает TRIM только для типа RAID 1, как исключение: для включения нужно убедиться, что драйвер Intel RST версии 11 и выше, и прошивка OROM (Legacy boot) или SataDriver (UEFI boot) версии 11 и выше, или старая версия, но пропатченная. TRIM поддерживается в Intel RSTe RAID 0/1/10 начиная с версии 3.7.0.1093.
Я решил создать неразмеченный раздел диска для over-provisioning.
1. При помощи Acronis Backup я снял образ диска. Также сохранил таблицу разделов (важно иметь первый сектор, последний сектор, GPT тип раздела, GPT уникальный идентификатор, имя раздела).
2. Перезагрузился в BIOS и сделал SSD Secure Erase. Если этого пункта нет в BIOS, то можно выполнить команду при помощи hdparam (или здесь и здесь, есть под Windows), HDDErase или HDAT2.
3. Собрал RAID 1 на двух дисках.
Здесь нужно сделать важное замечание: при инициализации массива RAID-контроллер считывает каждый сектор с одного диска и записывает его на второй. Теоретически это должно помешать всей нашей затее, и на одном диске не будет over-provisioning. Но тесты показали, что этот метод почему-то работает. У меня этому нет объяснений.
4. Загрузился с LiveCD и при помощи GPT fdisk создал нужную таблицу разделов: последний раздел на 104 ГБ меньше, чем раньше. Разделы нужно выравнивать (partition align) по размеру страницы диска, а не по размеру блока.
5. Восстановил из резервной копии каждый раздел.
После этого я полностью заполнил диск и запустил тесты. Это должно показать худший случай. Кеш Windows включён, регулярная запись кеша выключена, Inter RST write-back выключен, все тесты используют область диска фиксированного размера в 40 ГБ. Тестировать диски непросто, поскольку показатели могут меняться во времени. Ниже сведены показатели установившегося состояния.
Я сравню три состояния:
— Один диск без RAID, полностью заполненный, стандартная скрытая резервная область 6,58 %.
— Один диск без RAID, после запуска на нём TRIM свободного места.
— Два диска в RAID 1, полностью заполненные, стандартная скрытая резервная область 6,58 %.
— Два диска в RAID 1, полностью заполненные, over-provisioning 27,24 % (включая скрытую резервную область).
Анализ результатов:
— чтение с RAID 1 оказывается быстрее, чем с одного диска, невзирая на то, что у нас всего лишь firmware RAID.
— запись тем быстрее, чем больше нераспределенного пространства: на первом месте TRIM, на втором — наш самодельный over-provisioning.
Установившееся состояние не всегда достигается быстро. Посмотрим тест последней конфигурации (over-provisioning 27,24 %) в динамике и увидим худший случай:
Любопытный процесс идёт первые 400 секунд, после чего производительность возрастает и стабилизируется. Я думаю, параллельно с записью работает сборщик мусора, который дефрагментирует блоки и подготавливает их для записи. Такое поведение наблюдается не каждый раз, а время от времени. Видно, что последовательная запись проседает до 70 МБ/с, случайная запись — до 18000 IOPS. Эти показатели всё равно в два раза лучше, чем без over-provisioning (32 МБ/с и 7139 IOPS соответственно). Чтобы убедиться, что установившееся состояние на самом деле имеет такую высокую производительность, я также выполнил тест в течении 30 минут, при этом было записано на диск 490 ГБ со средним 69721 IOPS.
Кратко
— Если диск получает ATA TRIM от ОС, то беспокоиться не о чем, достаточно оставлять часть места на диске свободным.
— Если используются дорогие промышленные диски, то проверьте объём встроенной резервной области, если он достаточен, то проблем с записью не будет.
— В остальных случаях нужно оставить не размеченную область, чем больше её размер, тем меньше будет стандартное отклонение латентности записи.
— Иногда сборщик мусора не успевает подготовить чистые блоки и скорость записи может просесть и быть непостоянной.
— После over-provisioning установившаяся максимальная скорость записи повысилась с 7000 до 68000 IOPS, а средняя минимальная — с 6000 IOPS до 19000 IOPS.
На самом деле, речь сегодня пойдёт не только о бывших в использовании какое-либо время накопителях, ведь проблема низкого быстродействия может затронуть даже только что принесённый из магазина SSD. Конечно, физику не обманешь – со временем все твердотельные накопители будут терять производительность. Но причиной этому может стать не только проблема именно самого SSD. Обеспечить грамотное взаимодействие комплектующих и программного обеспечения в системе – не совсем простая задача для простых пользователей, кто не хочет (или кому попросту не надо) хоть мало-мальски разобраться в теме и послушать советы грамотных в этом плане людей. Кому-то проще переустановить операционную систему или добавить в список используемых приложений какие-то сомнительные «твикеры». Но ведь вдумайтесь — к примеру, простое с нашей точки зрения удаление файла состоит из достаточно большого количества этапов, в которых завязаны сразу несколько участников. И, если хоть один из них отработал задачу некорректно, то это сказывается на производительности диска. Что это за этапы? Кем или чем они выполняются? Как обеспечить стабильную работу? Во всём этом мы сегодня и разберёмся. Просто и наглядно, чтобы понятно было всем. И тогда станет ясно, что лечение симптомов низкой производительности SSD не поможет.
Вот теперь, вроде, всё.
Как оказалось – не всё так страшно, как выглядело не первый взгляд. От пользователя требуется выполнение всего нескольких рекомендаций, чтобы система работала корректно и радовала производительностью твердотельного накопителя долгое время. Повторим их напоследок – чистый дистрибутив операционной системы, актуальные драйверы и прошивки от производителя, а также отсутствие сторонних «настройщиков» системы, которые, по заверению их разработчиков, увеличивают производительность на 146%. Если проблема не аппаратная, то никаких нареканий к диску у вас не будет в течение всего срока жизни вашей системы. Так что никакого длинного заключения-словоблудства не будет – всё, что надо было сказать, уже сказано. Ёмких вам SSD, их высоких скоростей и стабильной работы!
Для получения дополнительной информации о продуктах HyperX и Kingston обращайтесь на сайты компаний.
В интернете много противоречивой информации по этому поводу, так что пришлось сесть и вникнуть в эту тему. Но для начала все по порядку. Очень много информации уже глубоко устарело и рождает кучу мифов и домыслов, на самом же деле все не так уж и плохо. TRIM позволяет вашему диску пожить более долгую жизнь, распределяя равномерно запись по всему диску. Тем самым диск выходит из строя намного медленней. (все это справедливо исключительно для SSD дисков поскольку у них есть проблема с количеством записей). Включить TRIM легко, однако если мы используем mdadm для создания RAID 1 и такой фокус естественно не прокатит поскольку мы монтируем уже виртуальный диск.
1. Выбор файловой системы — вариантов не так много Ext4 и Btrfs поскольку последняя официально не рекомендована для установки на рабочие станции и сервера, хоть и считается стабильной, так же сказывается отсутствие рабочих утилит для проверки и исправления файловой системы. Так что вариантов не так уж и много, вернее один. Ext4
2. Выравнивание разделов — очень много информации по этому поводу, много советов, все это сводится к одной единственной вещи, новый fdisk по умолчанию уже не поддерживает dos формат, а следовательно такой проблемы уже давно нет. В этом легко убедиться просто дайте вашей системе отформатировать диск, и вы увидите что начинается он не с нулевого сектора.
Однако когда начал делать скриншоты на одной из тестовых машин c centos на борту, он мне дал такой скрин
В debian 7 все прошло гладко. Суть решения проблемы отключение ДОС формата, в fdisk думаю если в centos поставить последний fdisk то проблема так же сама собой пропадет, или принудительно указать ненужность ДОС поддержки при форматирование диска.
Итог: новое ПО само решит эту проблему.
3. Включаем TRIM Если у вас диск подключен без программного рейда нам достаточно убедиться в том что само устройство поддерживает TRIM
Discard — включит TRIM
noatime — действительно не нужен при ssd так что смело выключаем
commit=XX — а вот его я не рекомендую это уже перебор. Срок жизни диска увеличится меньше чем на 1%
4. Свободное место — да действительно нужно и чем больше, тем лучше, но это справедливо для любого накопителя, особенно это касается носителя при заполнение более 80%, так что это утверждение справедливо и для SSD.
5. Отключение планировщика записей на диск — нет
6. Поддержка TRIM в mdadm — TRIM is support for in all new versions of mdadm.
TRIM и OpenVZ — Ядра OpenVZ поддерживает смотрим тут
8. Отключение логов системы — Не хотелось бы даже комментировать такое стремление, но поскольку оно активно обсуждается в сообществе и вероятно кем то используется то прокомментирую. НЕТ!
Лог файл спасет вас в экстренной ситуации и уж если не скажет что чинить так как минимум даст не повторить ошибку. Логи по степени важности ни разу не меньше чем бэкап всей системы. Так что удалить логи даже за пару секунд это критически невозможно, не говоря уже о умниках вообще отключающих их. Если вам так тяжко смотреть как логи используют ваш диск, вставьте еще 1 HDD и перенесите все логи на него. 1000 рублей не такое уж и дорогое решение данной проблемы.
9. Также коллеги рекомендуют отложенную запись. (сам не проверял). Все процессы в системе пишутся в tmpfs, а когда придет заданное время — то обращаются уже к диску. Добавляем строчки в /etc/sysctl.conf
Семь бед – один Deallocate
Многие слышали про команду TRIM. Те самые заветные четыре буквы, которые вызывают множество вопросов у рядового пользователя. TRIM – одна из команд ATA, отправляемая операционной системой с целью уведомления твердотельного накопителя о том, что данные с диска были удалены пользователем и занятые физические ячейки можно освободить. Стоит отдельно сказать про SSD с интерфейсом NVMe — эти диски обладают другим набором команд для работы, но аналог ATA команды TRIM там тоже существует — называется она Deallocate и, соответственно, является идентичной. Поэтому, далее при упоминании TRIM мы будем подразумевать и Deallocate тоже. К чему речь обо всём этом? Как раз именно проблемы с выполнением данных команд в подавляющем большинстве случаев и являются причиной низкой производительности накопителей. Конечно, другие проблемы мы тоже не оставим в стороне, но всему своё время.
В тот момент, когда вы удаляете данные с вашего накопителя, по факту удаляется запись в главной таблице файловой системы. То есть, сами данные остаются на месте, но область помечена на удаление. Сама «зачистка ячеек» происходит в определенное время, например, в момент простоя накопителя, пока вы отошли за чаем. Таким образом производители добиваются снижения износа памяти и увеличивают производительность своих накопителей в определённых сценариях. Именно очисткой этих ячеек и занимается контроллер, выполняя команду TRIM. К слову, после её выполнения, восстановление данных практически невозможно.
Совсем недавно мы рассказывали про технологию Secure Erase, которая схожа с TRIM, но затрагивает не только основные ячейки, но и служебные области, возвращая накопитель в полностью исходное состояние. Напомним, что Secure Erase можно выполнить на накопителе только без файловой системы и при определённых условиях. А технология TRIM как раз и требует наличие операционной системы со всеми вытекающими требованиями.
Что хорошо, а что плохо?
Если функция TRIM работала с самого начала, то сама по себе никуда она деться не может. Но совсем другое дело, если вы увлекаетесь разного рода твикерами, сторонними драйверами или прошивками, а также сборками операционных систем, якобы улучшенных. Все эти программы и сборки могут только навредить, если речь идёт о Windows 8 и, тем более Windows 10 – в этих ОС всё продумано как надо. В «семёрке» они могут чем-то помочь, но это скорее исключение из множества проблем, которые они могут принести.
Отдельно надо сказать несколько слов про NVMe накопители и драйверы для них. Приобретая высокоскоростной SSD, в ваших глазах должны отражаться полученные в бенчмарках заявленные скоростные показатели. Часто это так и есть, например – с накопителями Kingston. Установил и забыл, как говорится, наслаждаясь его высокими скоростями. Но с SSD других производителей это может быть не всегда так, что, очевидно, расстроит любого. Тут уже не отсутствие Deallocate является причиной недостаточного быстродействия, а стандартный NVMe драйвер. Да-да, при покупке NVMe SSD некоторых производителей обязательно приходится отправляться на сайт его сайт и скачивать соответствующий драйвер – разница со стандартным может превышать двукратную!
Объясним на пальцах, как раз их 20…
Когда вы создаёте файл, операционная система отправляет команду записи по адресу определенного логического блока. Когда вы удаляете данные с диска, эти блоки помечаются свободными.
При этом, данные останутся на диске пока контроллер не захочет их перезаписать.
Перед нами часть памяти, в которой находятся файлы А и В разных размеров, занимающих, соответственно, разное количество блоков. Сначала мы удаляем файл В, а затем записываем файл С на наш диск. Для наглядного представления ситуации, когда TRIM не работает, добавим простую иллюстрацию, в которой обозначены следующие состояния:
- Наличие файлов А и В.
- Удаление нашими руками файла В.
- Определённое время бездействия. Заметим, что помеченные на очистку блоки данных так и остались с данными в них.
- Запись файла С, но сначала – удаление файла В из ячеек.
А теперь что происходит, если TRIM работает. Снова по этапам:
- Наличие файлов А и В.
- Удаление нашими руками файла В.
- Определённое время бездействия, в которое помеченные на удаление блоки с файлом В очищаются.
- Запись файла С без каких-либо задержек в область, где был файл В.
То есть, логика работы совсем другая. Повторим пройденное — в момент удаления нами файла B отправляется команда TRIM, и, поскольку в SSD достаточно часто простаивает, он с радостью удаляет ненужные блоки практически сразу. И в момент того, как мы хотим записать файл С, то он сразу же записывается на диск, а не ждёт пока для него очистят блоки с мусором.
Можно ли эффективно использовать SSD без поддержки TRIM?
Вынесенный нами в заголовок вопрос довольно часто занимает умы системных администраторов. Действительно, что лучше, собрать из твердотельных дисков RAID массив, но потерять поддержку TRIM, или отказаться от отказоустойчивости в пользу высокой производительности? Ситуация усугубляется еще и тем, что немногие реально представляют себе механизмы внутренней работы SSD и ориентируются более на маркетинговые материалы, чем на реальную техническую необходимость.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Основной миф касательно SSD таков: на системах без поддержки TRIM производительность SSD будет стремительно деградировать. Почему и как это происходит обычно не сообщается, без TRIM будет плохо и точка. В тоже время большинство серверных конфигураций дисковой подсистемы TRIM не поддерживают, либо поддерживают, но в очень ограниченном объеме. При этом некоторую странность вызывает то, что ни производители железа, ни производители софта не спешат с этой "проблемой" что-либо делать.
Чтобы понять, для чего нужен TRIM и что это, раздутый маркетологами термин или насущная необходимость, разберемся как работает SSD. Мы не будем вдаваться в технические подробности и сознательно упростим модель до уровня достаточного для понимания происходящих процессов.
Первоначально вспомним, как воспринимают диск разные подсистемы ПК, участвующие в работе с ним. Приложения и ОС взаимодействуют с файловой системой, работая на уровне кластеров и таблицы файлов. О том, что находится ниже ОС не имеет никакого представления. Файловая система воспринимает диск как некоторое блочное устройство стандартного формата, также не сильно вникая в его внутреннюю суть, отдавая все вопросы на откуп драйверу контроллера запоминающих устройств. Тот, в свою очередь, воспринимает диск как некоторое LBA-устройство, не зная его внутренней структуры. О том, как именно конфигурация LBA соответствует физической конфигурации устройства знает только контроллер диска, который в свою очередь не имеет ни малейшего представления о файлах, разделах, кластерах и т.п.
Физически пространство SSD делится на страницы, которые являются минимально адресуемым участком памяти, для того, чтобы изменить ячейку памяти, необходимо считать страницу, изменить в ней необходимые данные и записать ее на прежнее место. Здесь возникает первая сложность, в отличие от HDD, в SSD писать можно только в заранее очищенные ячейки. При этом технически очистить отдельную страницу нельзя, очистке подвергаются только группы страниц, объединяемые в блоки.
Размеры страниц и блоков зависят от конфигурации памяти конкретного SSD, но, как типичное, можно принять значение 4 КБ для страницы и 512 КБ для блока. А теперь представим, что мы открыли файл и изменили в нем 100 байт данных. Для HDD проблемы нет, он считает нужный сектор (512 байт), изменит данные и перезапишет его. В реальности будет все немного по-другому, так как минимально адресуемым пространством ФС является кластер, то HDD перезапишет соответствующее количество секторов, но никаких дополнительных накладных расходов это не вызовет.
А вот SSD не может взять и просто так записать измененные данные. Для этого ему потребуется считать куда-то весь блок, очистить его и вернуть все данные назад. Поэтому вместо изменения и записи 4 КБ данных SSD придется записать 512 КБ данных, что не самым лучшим образом скажется на ресурсе ячеек. Кроме того, операция стирания ячеек достаточно медленная, по сравнению с записью в чистые ячейки и именно необходимостью стирания перед записью объясняется деградация производительности SSD.
Чтобы решить эту проблему в SSD применяется алгоритм "копирование при записи". Суть его заключается в следующем: при необходимости записи уже существующей страницы, она копируется в свободные ячейки, а сама помечается как доступная к очистке.
Это позволяет SSD сразу записывать измененные данные, не вызывая каждый раз процедуру очистки и не перезаписывая остальные данные блока. Это будет продолжаться до тех пор, пока не кончатся свободные ячейки.
Несложно заметить, что через некоторое время на диске вперемешку окажутся свободные, занятые и доступные к очистке страницы. Здесь вступает в действие алгоритм внутренней оптимизации, именуемый "сборкой мусора". Он перемещает данные на SSD таким образом, чтобы сгруппировать доступные к очистке страницы в отдельные блоки и очистить их.
Именно от эффективности данного механизма зависит, как долго диск сможет поддерживать высокую производительность при интенсивной записи на него. Основное условие высокой скорости записи на SSD - это наличие свободных ячеек. Эффективность алгоритма уборки мусора отвечает за то, как быстро доступные к очистке ячейки будут становиться свободными.
Из-за чего наступает деградация? От того, что свободные ячейки кончаются, например, мы полностью заполнили пространство диска. В этом случае у SSD все равно остается пространство для маневра в виде резервной области, которая предназначена для замены вышедших из строя ячеек, но достаточного количества свободных страниц может не оказаться и там. Вопреки еще одному расхожему мнению, резервная область SSD используется всегда, это делается в целях выравнивания нагрузки, просто она недоступна для размещения пользовательских данных.
Если размер резервной области небольшой, а интенсивность записи высокая, то сборщик мусора будет не успевать эффективно очищать блоки, и мы получим деградацию производительности диска.
Заметьте, мы до сих пор ни словом не обмолвились о команде TRIM. Может быть это какая-то передовая технология, включение которой поможет резко изменить ситуацию? К сожалению - нет! Для чего тогда нужен TRIM?
Снова самое время вспомнить, что файловая система не имеет не малейшего представления о физическом размещении данных на носителе, это прерогатива контроллера диска. Поэтому удаление файла в современных файловых системах физически не происходит, удаляется только запись в таблице файлов, после чего данное место считается свободным. При этом сами данные будут находится на диске до тех пор, пока не будут перезаписаны. При этом файловая система никак не сообщает контроллеру о таких данных, и он продолжает считать эти ячейки занятыми. У SSD это приведет к ситуации аналогичной тому, когда диск полностью заполнен, хотя с точки зрения ФС там много свободного места и она будет пытаться писать туда.
В этом случае SSD будет полностью считывать блок в память, очищать его и заново записывать измененные данные.
А как же технология сборки мусора? А никак, потому что убирать ей нечего. Эти ячейки свободны только с точки зрения файловой системы, с точки зрения контроллера диска в них записаны данные. Понять, что эту страницу можно очищать диск сможет только тогда, когда система попытается туда что-либо записать, а для того, чтобы быстро выполнить запись нужны свободные ячейки.
Для того, чтобы файловая система сообщила контроллеру, что эти данные удалены и придумали команду TRIM, ее задача - пометить страницы с удаленными данными как доступные к очистке, а дальше в дело вступит все тот-же сборщик мусора.
Таким образом команда TRIM никак не влияет на производительность SSD, если вы заполнили диск практически полностью, то получите деградацию производительности что с поддержкой TRIM, что без. Если вы удалите файлы и даже принудительно пошлете команду TRIM - чуда не произойдет, производительность будет оставаться низкой до тех пор, пока сборщик мусора не очистит достаточно свободных ячеек.
Если мы разместим на SSD базу данных или виртуальный жесткий диск и будем активно работать с ними, то никакой TRIM нам не нужен. Если на диске достаточно свободных ячеек и эффективно работает сборщик мусора - производительность будет поддерживаться на высоком уровне. Падение производительности произойдет только тогда, когда количество свободных ячеек уменьшится и сборщик мусора не будет успевать очищать их в необходимых количествах. Это может произойти при использовании всего доступного пространства диска и TRIM на это никак повлиять не может.
Команда TRIM, в первую очередь, предназначена для настольных систем и системных разделов, где файлы активно создаются и удаляются, в большинстве серверных сценариев, где идет изменение уже записанных данных, необходимости в ней нет.
Здесь самое время вспомнить про корпоративные серии SSD, которые зачастую не блещут производительностью, но зато предлагают высокую надежность и поддерживают эффективную работу даже без поддержки TRIM. За счет чего это происходит? За счет большего размера резервной области. Это позволяет всегда иметь достаточный запас свободных ячеек и благотворно сказывается на эффективности работы сборщика мусора. Так как пользователь не может непосредственно писать в резервную область, то в ней могут быть страницы только трех видов: свободные, занятые и доступные к очистке. Занятых страниц, которые ФС считает свободными, там быть не может.
Обычные SSD имеют размер резервной области в 6-7% от емкости диска, этого размера явно недостаточно для поддержания высокой производительности, корпоративные диски имеют гораздо больший объем резервной области, что напрямую сказывается на их стоимости. Это позволяет им уменьшить износ каждой доступной пользователю ячейки и эффективно работать в RAID-массивах без поддержки TRIM. Хотя если вы заполните твердотельный накопитель "под завязку", то никакой TRIM вам не поможет.
А что делать владельцам обычных или "корпоративных" бюджетных дисков? Ответ прост - обеспечить диск достаточным количеством свободных ячеек. Самый простой способ сделать это - разметить не всю доступную емкость диска. Как показывает практика - резерв в 20-25% емкости накопителя позволяет эффективно использовать даже полностью заполненный диск без поддержки команды TRIM.
Чтобы убедиться в этом, мы провели небольшой эксперимент. Взяли старый SSD OCZ Agility 2 , алгоритмы уборщика мусора которого в разы уступают современным алгоритмам, полностью заполнили его на системе без поддержки TRIM, затем еще раз сделали тоже самое, только создав "резервную область" в 25% емкости накопителя.
Итак, диск очищен при помощи команды Secure Erase фирменной утилитой и все его ячейки являются свободными. Снимаем показатели быстродействия при помощи AS SSD Benchmark.
Сценарии реального использования:
Производительность данного SSD, по современным меркам, конечно невелика, но нас интересуют не абсолютные числа, а сохранение производительности при работе в тяжелых условиях, в этом случае использование старой модели даже интереснее, если справится она, то современные диски, с более совершенными алгоритмами уборки мусора, справятся тем более.
После чего мы подключили его к виртуалке под управлением Windows Server 2003 и полностью заполнили, затем удалили все данные и вернули назад. Несмотря на то, что Windows 8.1, в которой мы производим замеры, есть поддержка TRIM - это ни на что не влияет, так как принудительно данную команду никто не посылал, а Windows 8.1 сделает это не раньше, чем запишет и удалит данные и то, только для этих страниц.
Деградация производительности на лицо:
Проседание производительности от 20 до 50% в синтетике и 30-35% в сценариях:
Теперь снова выполним Secure Erase и разметим не все пространство диска, выделив под резерв 25%:
Важно! Перед тем как переразметить твердотельный диск его следует полностью очистить от данных при помощи фирменной утилиты для того, чтобы в резервную область попали только свободные ячейки. Если просто удалить разметку и выполнить ее заново или изменить границы разделов, то это не даст желаемого эффекта.
Затем снова заполним диск в среде Windows Server 2003 и удалим данные, после чего еще раз выполним тест:
Диск уверенно держит производительность, так как свободных ячеек для записи достаточно, несмотря на то, что был заполнен полностью и с точки зрения контроллера SSD свободных ячеек в доступной пользователю части диска нет.
Какие выводы следует сделать из этого материала? Несмотря на то, что в сознании многих TRIM является чуть ли не панацеей и обязателен к применению, на производительность диска он не влияет. Это всего лишь способ сделать работу уборщика мусора более эффективной. На производительность диска влияет только то, какое количество свободных ячеек есть в наличии и их достаточности для обслуживания текущих операций записи.
За то, с какой скоростью диск и как эффективно диск способен очищать блоки, отвечает уборщик мусора. Более эффективный алгоритм уборщика позволяет использовать меньший размер резервной области.
Также следует помнить, что в большинстве серверных сценариев команда TRIM просто не требуется, поэтому если выбирать приходится между RAID без TRIM или одиночный диск с TRIM, выбирать следует первое. Тем более, что обеспечить высокую производительность диска несложно самостоятельно.
Использование одиночного диска с более частым бекапом также допустимо, но такое решение принимается, как правило, по экономическим соображениям.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
TRIM, а есть ли ты вообще? И, если есть, то работаешь ли?
Узнать, поддерживает ли SSD команду TRIM можно при помощи достаточно большого количества свободно распространяемого программного обеспечения. Возьмём, к примеру, CrystalDiskInfo:
Но демонстрация поддержки – не есть работа. Для начала пройдёмся по ситуациям, когда TRIM надо запускать хитрым способом или данная команда не работает вовсе. Конечно, со временем ситуация может поменяться, но пока дела обстоят следующим образом:
- Стандартные драйверы Windows не могут выполнять TRIM на RAID массивах. В зависимости от системы и типа RAID массива, проблему может решить драйвер от Intel под названием Rapid Storage. Поддерживаются массивы 0 и 1 с драйвером версии Enterprise.
- Поддержка TRIM в Windows начинается с версии операционной системы с цифрой 7. Vista и, тем более, XP не поддерживают TRIM на уровне ОС. Конечно, эта проблема решается сторонним программным обеспечением, но тут всё на ваш страх и риск – рекомендовать это мы не можем и не будем.
- Команда Deallocate (TRIM для NVMe SSD) поддерживается только с Windows 8 и новее.
- TRIM не работает на виртуальных дисках.
- TRIM работает только в режиме AHCI.
- TRIM не работает при подключении накопителя через USB переходники.
- TRIM не работает в с файловой системой FAT32 (и более «лохматых»).
Для начала – попробуем это узнать прямо у операционной системы. В запущенной от имени Администратора командной строке или PowerShell вводим команду «fsutil behavior query disabledeletenotify» без кавычек и смотрим на результат. Если в выводе значатся «0», то это хорошо – TRIM работает. Если «1», то функционал TRIM недоступен. Всё верно: ноль – включённая команда, 1 – выключенная команда.
Проблемы, проблемы вместо обеда
Самая распространённая проблема – наследование. Само собой, речь идёт про Windows до версии 8. Например, когда пользователь ставит в старые системы SSD или переходят с HDD на SSD без изменения настроек BIOS (если это необходимо) или вообще путём клонирования разделов или диска целиком. Напоминаем, что TRIM доступен только в режиме AHCI. К примеру, у многих материнские платы могут работать в двух режимах AHCI и IDE. Соответственно, если SSD подключён к такой плате именно в режиме IDE, то TRIM работать не будет. Просто наличие режима AHCI не решает проблему – Windows установит драйверы согласно выбранному IDE. Казалось бы, ситуация может встречаться редко, но на самом деле – нет. Если с настройками BIOS вы не дружите, то хотя бы проверить режим работы надо. Сделать это можно в диспетчере устройств в разделе «Контроллеры IDE ATA/ATAPI»:
Помните, что просто так после установки Windows переключить режим работы с IDE на AHCI (и обратно) без дополнительных манипуляций не выйдет – операционная система попросту не загрузится. Решения этой проблемы существуют (даже от самой Microsoft), но рекомендовать их не стоит. Требуется изменение параметров реестра, добавление нужного драйвера и готовность к переустановке ОС в случае неудачи.
Что касается Linux-систем, то обязательным условием, помимо аппаратной составляющей, является файловая система ext4. Включение TRIM указывается опцией discard в файле fstab. Дополнительными полезными опциями для раздела станут noatime (realtime или nodiratime), которые снизят запись путём отключения обновления времени последнего доступа к файлам и директориям. Сама же команда TRIM запускается при помощи программы fstrim – «fstrim / -v» без кавычек и с правами рута.
Вспомним ещё про Secure Erase. Восстановить производительность этой функцией можно. Только вот вряд ли надолго. Особенно, если вы быстро забиваете свой накопитель новыми данными. Так что как временное решение – пойдёт, но оно всегда будет оставаться временным.
Ещё добавим про SLC-кеширование, которое достаточно часто используется у многих SSD-накопителей без привязки к интерфейсу. Невысокая скорость записи большого количества файлов (или больших файлов) после определённого порога не проблема, а особенность работы. Суть кеширования состоит в том, что сначала записываемые данные попадают в специальную область памяти, а уже затем записываются в основную память в фоновом режиме. Когда выделенная высокоскоростная память заканчивается, то данные начинают записываться непосредственно в память на заметно сниженной скорости – от 50 до 150 МБ/с. Это совершенно нормальный режим работы накопителей с SLC-кешем, поэтому здесь ничего сделать невозможно от слова совсем.
Читайте также: