Надо ли дефрагментировать SSD диск, увеличится ли производительность – ответ

Автор Вероника и Влад

Дата
Сен 25, 2016
6 142

Поделиться

Популярность твердотельных накопителей (SSD или Solid State Drive) растет в геометрической прогрессии. Классические магнитные HDD диски стремительно уходят в прошлое или чаще играют роль объемных хранилищ для файлов, а современные операционные системы рекомендуется устанавливать на SSD винт.

• Facebook
• LiveJournal
• Blogger

Современные операционные системы рекомендуется устанавливать на SSD винт

• Можно ли делать дефрагментацию SSD?
• Какие операционные системы лучше использовать для SSD диска?
• Что будет, если на диске осталось мало места?
• Можно ли хранить большие файлы на SSD?
• Что нельзя делать еще?
• Итоги

По сравнению с традиционным HDD, SSD жесткий диск обладает рядом преимуществ:

1. Ускоренная загрузка и доступ к данным.
2. Бесшумная работа.
3. Повышенная надежность.

Но вместе с этим зародилось немало вопросов касательно использования твердотельных накопителей. Наиболее распространенные:

• можно и нужно ли дефрагментировать SSD диск?
• вредна ли частая перезапись?
• можно ли форматировать SSD диск?
• можно ли заполнять SSD файлами до отказа?
• как продлить жизнь SSD диску в Windows 7?

И так далее. Но чем больше вопросов, тем и мифов относительно работы Solid State Drive. Давайте по порядку разберемся, что правда, а что вымысел и как продлить жизнь SSD.

Как обезопасить SSD от вредного влияния и не убить диск за две недели?

Я только что получил свой первый SSD. И у меня работает мониторинг SSDLife в фоновом режиме. После этого я установил все программное обеспечение и протестировал SSD. Программа SSDLife сказала, что «Total Data written, GB” = 52.1 (40GB используемого пространства, 70GB — свободного).

То есть, на SSD около 40 Гб данных, при этом записано 52,1 ГБ?

Особенность твердотельного накопителя — данные записываются в блоках. Блок может содержать 256Кб: 256 * 1000 * 8 двоичных разрядов. Для изменения хотя бы одной из этих цифр, вы должны переписать весь блок. То есть, ваша операционная система видит 1 бит, но износ SSD эквивалентен 256Кб: разница в 2,048 млн раза.

Это означает, что формула (РАЗМЕР SSD) * (циклы) = общая данные, записанные на SSD до выхода из строя

это только для лучшем случае, который позволил бы вам писать данные от 1000 до 1000000 раз до отказа. Но, даже в худшем случае, это более вероятно для всех небольших циклов записи на SSD. Это подтверждается в

История вопроса

Единственная запись блога на английском языке за полтора года набрала 60 тысяч просмотров (у русской всего на 15 тысяч сессий больше). Ссылка на нее всплывала на некоторых крупных форумах, но особого движения не было. А потом пришел Хансельман.

Кто такой Скотт Хансельман

Скотт Хансельман – евангелист Microsoft в сфере разработки, а также учитель, спикер, программист и блогер. Я давно читаю его записи о программах и эффективной работе в ОС, хотя их все меньше и меньше в последнее время.

В моем понимании, Скотт для разработчиков – это примерно как Марк Руссинович для ИТ-специалистов (возможно, чуть поменьше калибром). Мы, кстати, пересекались на летней конференции DevCon 2012, куда он был приглашен в качестве спикера. Он охотно раздавал автографы и позировал на фото с участниками и MVP.

Что утверждала Microsoft

И вот почти через год после публикации статьи о дефраге Скотт пришел ко мне в блог!

(Перевод) Windows не дефрагментирует SSD. И точка. Если диск определился как SSD, его не дефрагментируют, ни при каких обстоятельствах. Это просто сообщение-пустышка. Никакого бага тут нет, извини.

«О как!», подумал я, попутно отметив, откуда дует ветер. Действительно, в Твиттере кто-то попросил Скотта сообщить о проблеме продуктовой группе, но тот решил просто расставить точки над i своим весом, не вникая в статью. Когда я в блоге и Твиттере попросил его обращать внимание на факты, то получил в ответ ссылку на SuperUser с той же мантрой.

Однако Скотт все же задал вопрос внутри компании и в тот же день опубликовал ответ.

@mdsharpe confirmed just now. Windows DOES NOT Defrag SSDs. Period.
— Scott Hanselman (@shanselman) February 4, 2014

(Перевод) Только что получил подтверждение. Windows НЕ Дефрагментирует SSD. Точка.

@mdsharpe I just talked to that team. Bad message but no actual defragging happens.
— Scott Hanselman (@shanselman) February 4, 2014

(Перевод) Я только что общался с той командой. Плохое сообщение, но в реальности дефрага не происходит.

Поскольку я продолжал гнуть свою линию в Твиттере, Скотт отправил меня к кому-нибудь из команды Windows, указав на ее конкретного представителя (очевидно, с ним он и общался). На мое бодрое письмо (в копии, кстати, стоял один из читателей блога) тот не ответил, хотя является ведущим достаточно популярного шоу Defrag (!!!) на Channel 9, где решает по три проблемы с Windows за эпизод.

И что с ними делать? Я добавил в английскую запись четыре вопроса к продуктовой группе и предложил не беспокоить меня ссылками на устаревшее капитанство других сайтов.

Вода камень точит

Однако нашелся еще один упорный товарищ, который прочел обмен мнениями в Твиттере, решил проверить все сам и 10 месяцев спустя поймал за руку Windows 8.1. Он опять обратился к Хансельману, опубликовав скриншот выполняющегося дефрага вкупе с очевидной нагрузкой на диск.

@shanselman @0utsideTheBox finally I’ve caught my up2date Windows 8.1 doing defrag on SSD (with proof attached).. pic.twitter.com/lPXdpfciHf

— Patrick Heyer (@patthemav) November 11, 2014

Возможно, Патрик был не единственным, т.к. в этот раз Скотт решил поговорить с другой командой – файловой системы. И вскоре отрапортовал, что ему открылось тайное знание, но бояться нечего – ждите статьи в блоге. Наконец, она появилась.

Какова продолжительность жизни SSD-диска?

SSD — накопители более надежны, чем жесткие диски, и должны служить до 20 лет, по крайней мере, не беря во внимание ухудшение производительности.

И это то, что мы могли бы назвать усредненным показателем. Вы можете придумать срок жизни SSD в худших случаях, если хотите. Но я могу вас заверить, что они выглядят не слишком оптимистично!

Давайте же максимизируем срок службы нашего SSD путем выравнивания износа и сводя к минимуму все эти маленькие циклы записи, используя простые и передовые технологии…

Дискуссия и опрос

Как вам история? По-моему, это очень интересный случай из разряда, когда правая рука не знает, что делает левая, но думает, что знает

Проблема тут еще в том, что слова сотрудника Microsoft (особенно известного технического специалиста) автоматически получают статус истины и переводят противоположные утверждения в категорию ошибочных. Доказать обратное становится почти невозможно, вне зависимости от объема представленных доказательств.

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

Опрос призван выявить ваше отношение к дефрагу после того, как стала известна его причина. Понятие «дефраг отключен» одинаково применимо к выключению задания в планировщике и защиты системы. Напишите в комментариях, как вы проголосовали и поделитесь собранными сведениями

, если ваша конфигурация соответствует заданным критериям.

Реакция читателей блога на новость, что дефрагментация SSD в Windows 8+ не является багом https://t.co/Qd9st6jnNc pic.twitter.com/JprVH9iRQM

— Windows Outsiders (@0utsidethebox) January 31, 2015

Убедитесь, что функция TRIM включена

Во-первых, нет смысла проверять и пытаться включить TRIM, если ваш ssd диск не поддерживает эту технологию. Как узнать, поддерживает ли ваш SSD-диск функцию TRIM? Самый простой способ — получить эту информацию через программку CrystalDiskInfo.

В поле Supported Features можно видеть, поддерживает ли SSD TRIM:

Следующий шаг — проверить, знакома ли ваша операционная система с функцией TRIM. В ОС Windows 7 вы можете разузнать это с помощью команды fsutil behavior query disabledeletenotify. Если результат равен нулю, операционная система использует TRIM.

В случае, если система не признает ваш диск как SSD, вы должны обнаружить и устранить неисправности. Руководствуйтесь информацией, содержащейся в диспетчере устройств и свойствах SSD. Возможно, вам нужно обновить драйверы вашего дискового контроллера для того, чтобы операционная система воспринимала накопитель как SSD.

Какие операционные системы лучше использовать для SSD диска?

Команда TRIM — способ уведомить Solid State Drive о возможности физического удаления блоков данных, уже не содержащихся в файловой системе. Рекомендуется выбрать для установки на твердотельный накопитель ОС, поддерживающую такую команду. То есть операционная система для SSD должна современной. Идеально подойдут Windows 7, 8, 8.1 и 10.

Сама команда TRIM появилась с распространением , чтобы новые технологии хранения данных смогли составить конкуренцию HDD. Соответственно, операционные системы Windows Vista, XP и более ранние не подходят для

установки на SSD. Вы можете их использовать, но работать они будут медленно.

Отключаем файл подкачки SSD

Файл подкачки (своп) необходим для улучшения быстродействия операционной системы в ресурсоемких приложениях (графические пакеты, редакторы видео, игры). Кроме того, если запущено много «тяжелых» программ и оперативная память не справляется с объемом данных, незадействованные приложения временно хранятся в свопе.

Оптимальный размер файла подкачки примерно равен 3/2 размера ОЗУ. Если у вас более 8 Гб ОЗУ, на SSD файл подкачки не нужен. Попробуйте отключить его и протестировать компьютер некоторое время. Вряд ли вы заметите какие-либо проблемы с производительностью.

Узнать объем оперативной памяти компьютера и отключить его на SSD можно в окне «Свойств системы» (Win+Pause Break).

1. Откройте диалог «Быстродействие» (Мой компьютер ->Свойства системы ->Параметры быстродействия (см. предыдущую тему)).
2. Во вкладке «Дополнительно» нажмите кнопку «Изменить».
3. В окне виртуальная память напротив названия системного диска показан размер файла подкачки. Выбираем SSD-диск — устанавливаем опцию «Без файла подкачки» — кнопка «Задать» для применения изменений.

Можно ли хранить большие файлы на SSD?

В большинстве случаев пользователи используют SSD для операционной системы и приложений.

Программа, запущенная с твердотельного накопителя будет работать быстрее, чем с HDD, а ОС быстрее загружаться.

Для хранения пользовательских файлов лучше использовать обычный HDD, работающий параллельно. Почему?

Во-первых, потому что емкость твердотельного диска зачастую невелика, а во-вторых стоимость SSD диска равна цене в разы более объемного HDD. Первый ускоряет загрузку и работу операционной системы и всех программ, да и по объему подходит только для них. Но не всегда есть возможность установить HDD (в ультрабуках).

ПОСМОТРЕТЬ ВИДЕО

В этом случае рекомендуется приобрести внешний hdd. Он лучше подходит для хранения фильмов, музыки и других больших файлов. На самом деле, ничего плохого с ним не произойдет, если хранить на нем большие файлы, но пока объемы таких дисков малы, а стоимость велика, лучше использовать их там, где они демонстрируют уверенный прирост производительности.

Спящий режим (гибернация)

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

powercfg /hibernate off

выполнив ее от имени администратора. Это позволит отключить опцию спящего режима и удалить файл гибернации. Переместить файл спящего режима невозможно.

Индексирование поиска

Большинство людей считают, что индексатор поиска необходим, так как он значительно ускоряет поиск данных на жестком диске.

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

Другой способ разобраться с индексатором — сократить места индексации до минимума, если вы точно знаете, что искать там ничего не будете.

Нивелирование износа

Но расстраиваться не стоит, количество циклов удаления/записи SSD диска не так уж и мало. А в добавок, современные SSD диски имеют технологии, которые увеличивают КПД записи на диск и уменьшают нагрузку на ячейки информации. Наиболее важная из таких технологий это алгоритм нивелирования износа (wear-leveling algorithms), с помощью которого данные записываются равномерно по всему объёму накопителя, с помощью чего достигается максимальный срок его службы. Причём, SSD накопители большего объёма имеют больший срок службы, чем те, которые поменьше.

На сколько же продолжителен срок службы SSD накопителя? Для того, чтобы пользователи могли оценить длительность службы SSD накопителя, большинство производителей показывают её как количество объёма, которое можно записать на диск за всё время его использования. Рассчитывается данная величина в TBW (Total Bytes Written).

Например, такой объём как 220 TBW обозначает, что на диск может быть записано 220 терабайт данных до того момента пока он станет ненадёжным. Это означает, что если пользователь будет записывать на диск 50 ГБ данных каждый день, то такой диск прослужит 12 лет.

Большинство пользователей никогда не пишут на диск больше чем 50 ГБ в день. И такое случается редко, а большинство других дней на диск не записывается значительно меньше или вообще ничего. Причём, чтение документов или просмотр фотографий не является процессом записи, это чтение, которое не влияет на продолжительность службы диска. Только копирование файлов из другого диска, загрузка файлов или редактирование документов подразумевает запись информации на диск.

Это говорит о том, что если использовать SSD диск в таком же режиме, как и HDD диск, то сроки их службы должны быть сопоставимы.

Временные файлы, кэш и журналы

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

Например Google Earth хранит кэш образов мест, которые вы посетили, поэтому всякий раз, когда вы используете Google Earth, производится запись изображений на SSD. Давайте посмотрим в следующих главах, как найти «виновников» и в дальнейшем использовать точки соединения, когда мы не можем переместить или отключить их.

Как почистить кэш?

Как отключить автоматическую дефрагментацию SSD накопителя?

Из всего, что вы сегодня узнали, у вас, возможно, возник вопрос «А не включена ли у меня автоматическая дефрагментация SSD? И как ее отключить?». Спешу вас успокоить. Если вы используете Windows 7 или выше, то система сама отключает автоматическую дефрагментацию, как только видит SSD накопитель у себя на борту. Поэтому беспокоиться не о чем.

А что касается Windows XP или Vista, то использование SSD накопителей с такими версиями операционных систем настоятельно не рекомендуется. Они полностью несовместимы. Это приводит к очень быстрому износу SSD накопителей.

Монитор ресурсов Windows

Давайте взглянем на встроенный монитор ресурсов в новых версиях Windows:

1. Введите ‘Monitor’ Resource в стартовом меню и запустите его (или команда resmon.exe через Пуск — Выполнить).
2. Перейдите во вкладку «Диск».
3. Отсортируйте Столбик ‘Процессы с дисковой активностью’ на ‘Запись (байт/с)’. Это позволит вам оценить объем записей на диск в вашей системе.

Если вы хотите получить больше данных, понадобится утилита Process Monitor.

Утилита Process Monitor

Скачаем программку Process Monitor от Microsoft Sysinternals и настроим фильтр на записи:

1. и запустите утилиту.
2. Нажмите на кнопку «‘Reset’ для сброса фильтра.
3. Установите фильтр ‘Operation contains WRITE then Include’, затем нажмите кнопку «Add».
4. Затем нажмите кнопку «Применить», а затем нажмите кнопку «OK».
5. Дополнительно можно отфильтровать список по вашему SSD диску.

Теперь вы будете видеть происходящие операции записи в реальном времени. Также можно выбрать отдельный элемент и узнать подробную информацию о записи. В меню «Tools» есть «File Summary», эта команда позволяет ознакомиться со всем набором записей в разных вкладках.

Что лучше всего скопировать на SSD?

Вы должны поместить на SSD файлы, которым действительно требуются быстрая производительность. В основном это актуально для программ и игр. Размещение видеофайлов на SSD не даст заметного ускорения по сравнению с жестким диском. Это же относится к различным документам.

Изображения, фото будут загружаться быстрее в таких программах и пакетах, как Adobe Lightroom. Музыка будут проанализирована быстрее в DJ программах вроде Traktor Studio. Впрочем, текущие размеры SSD не совсем вписываются в эти задачи, так что облом.

Тем не менее, фотографии и музыка — хороший пример данных. Если вы сохраняете их единожды и не планируете редактировать, смело перемещайте эти данные на SSD.

Ещё один взгляд на вопрос «нужна ли дефрагментация для SSD»

Несомненно, вопрос, вынесенный в заголовок статьи, не нов, поднимался не раз и по нему достигнут консенсус «не особо нужна, и даже может быть вредна». Однако недавнее обсуждение в комментариях заставило меня ещё раз задуматься.

Со временем любой SSD всё равно сильно фрагментируется (внутри, в FTL)… Свежезаписанный SSD при линейном чтении даст высокую скорость, а уже поработавший — гораздо ниже, потому что линейными оно будет только для вас.

Да, обычно такое не должно происходить: или мы пишем «понемногу» в мелкие файлы/небольшие блоки метаинформации ФС (скорость линейного чтения которых нас не особо волнует), либо же мы пишем «помногу» в большие файлы и всё будет хорошо. Бывает и дозапись мелкими блоками в большие файлы — логи, например, однако они относительно короткоживущие и особой проблемы я тут не вижу. Но легко представился вполне реальный сценарий, при котором всё-таки внутренняя фрагментация SSD может проявиться: файл базы данных, в который идёт достаточно активная случайная запись. Со временем он (оставаясь нефрагментированным на уровне операционной системы) окажется физически очень даже фрагментированным, что может существенно снизить скорость seq scan, резервного копирования и т.п.

Для проверки я написал скрипт и провёл тесты.

Спойлер: проблема присутствует (существенно влияет на производительность) только на одной из попавшихся под руки моделей (и та позиционируется производителем не как datacenter, а как десктопная/ноутбучная).
Про что тут вообще речь? Какая ещё фрагментация внутри SSD?
Если в двух словах, SSD устроен очень непросто. В NAND flash можно писать (точнее стирать) только большими блоками. А операционная система видит SSD как набор 512-байтовых (или 4096-байтовых) секторов, каждый из которых может быть адресован независимо. Чтобы как-то это совместить, придумана такая вещь, как FTL (flash translation layer): данные во flash-памяти лежат не последовательно, а (очень условно) в том порядке, в котором они были записаны, что-то вроде log-структурированных файловых систем. Такие структуры очень хорошо обрабатывают случайную запись, превращая её в последовательную, но, увы, ничто не бывает бесплатно — в результате зачастую последовательное чтение превращается в случайное.

Алгоритмы, по которым работают FTL, закрыты, однако, насколько мы можем судить, у разных производителей они могут кардинально различаться. Соответственно, кардинально может различаться и поведение накопителей под нагрузкой. Именно это мы и будет исследовать.

Идея скрипта: создаём файл на несколько гигабайт, заполненный случайными данными, замеряем скорость последовательного чтения. Далее используя случайный доступ переписываем часть тестового файла и снова измеряем скорость линейного чтения. Если наши подозрения верны, то теперь чтение из файла будет идти медленнее. После каждой записи делаем по три операции чтения с задержкой между ними на случай, если какой-то накопитель в фоне производит дефрагментацию и потом скорость чтения улучшится.

Немного о том, почему нужно заполнять SSD перед тестированием

Не раз встречал обзоры, в которых запускают чтение с нового накопителя, получают какие-то фантастические цифры и, ничтоже сумняшеся, публикуют их. Через какое-то время тест повторяют уже на не столь девственном диске, и вдруг оказывается, что время доступа выросло, а скорость, соответственно, упала. Дело в поддержке TRIM: контроллер внутри SSD может «знать», что в конкретном блоке нет полезных данных, информация об этом хранится в FTL. И при запросе на чтение из такого блока он не обращается к медленной NAND flash, а сразу возвращает нули. На новом накопителе все блоки помечены как неиспользуемые, соответственно, в тестах на чтение он готов ставить рекорды. Только нас же интересует с какой скоростью SSD умеет отдавать не нули, а данные.

Кроме этого, некоторые накопители умеют сжимать данные, и на хорошо сжимаемых тестовых данных могут показывать не совсем те результаты, которые будут в реальной жизни.

Поэтому, перед тестированием стоит заполнять SSD несжимаемыми данными (в linux хорошим источником может служить /dev/urandom).

шелловский скрипт

тестовый файл создаётся в текущем каталоге.

тестировал только под linux c dash, coreutils и fio из debian buster, с другими дистрибутивами навряд ли будут проблемы, а вот под freebsd и другие операционные системы скорее всего скрипт придётся «допиливать».

echo preparing… dd if=/dev/urandom of=testfile bs=1M count=4096 status=none sync for A in 1 2 3; do sleep 10 dd if=testfile of=/dev/NULL bs=1M iflag=direct done for A in 50 200 800 4000; do echo fio: write ${A}M… fio —name=test1 —filename=testfile —bs=4k —iodepth=1 —numjobs=1 —rw=randwrite —io_size=${A}M —randrepeat=0 —direct=1 —size=4096M > /dev/NULL sync for B in 1 2 3; do echo sleep ${B}0 sleep ${B}0 dd if=testfile of=/dev/NULL bs=1M iflag=direct done done echo sleep 3600 sleep 3600 dd if=testfile of=/dev/NULL bs=1M iflag=direct

Обнаружилось, что NVMe-накопители intel у меня сейчас только на серверах с windows; пришлось с помощью гугла, stackexchange и какой-то матери слепить вариант и под винду

вариант на ps

Из внешних зависимостей только fio; путь к exe-файлу и временному файлу указывается в первых строчках скрипта.
$testfile = «c:\temp\testfile» $fio = «c:\temp\fio-3.18-x64\fio» echo «preparing…» $filestream = New-Object System.IO.FileStream($testfile, «Create») $binarywriter = New-Object System.IO.BinaryWriter($filestream) $out = new-object byte[] 1048576 For ($i=1; $i -le 4096; $i++) { (new-object Random).NextBytes($out); $binarywriter.write($out) } $binarywriter.Close() For ($i=1; $i -le 3; $i++) { sleep 10 $time = Measure-Command { Invoke-Expression «$fio —name=test1 —filename=$testfile —bs=1M —iodepth=1 —numjobs=1 —rw=read —direct=1 —size=4096M» *>$NULL } $seconds = $time.Minutes*60+$time.Seconds+$time.Milliseconds/1000 echo «read in $seconds» } foreach ($A in 50,200,800,4000) { echo «fio: write ${A}M…» Invoke-Expression «$fio —name=test1 —filename=$testfile —bs=4k —iodepth=1 —numjobs=1 —rw=randwrite —io_size=${A}M —randrepeat=0 —direct=1 —size=4096M» *>$NULL For ($i=10; $i -le 30; $i+=10) { echo «sleep $i» sleep $i $time = Measure-Command { Invoke-Expression «$fio —name=test1 —filename=$testfile —bs=1M —iodepth=1 —numjobs=1 —rw=read —direct=1 —size=4096M» *>$NULL } $seconds = $time.Minutes*60+$time.Seconds+$time.Milliseconds/1000 echo «read in $seconds» } } rm $testfile
Получил следующие результаты:

• фоновой дефрагментации в тестируемых моделях не обнаружено: скорость чтения не повышается через некоторое время после записи, в том числе длительный «отстой» (час и даже более суток) ничего не меняет, поэтому в таблице ниже привожу просто лучший результат из трёх запусков;
• под windows почему-то время чтения менее стабильно и оказалось выше ожидаемого (впрочем, возможно, дело в том, что эти сервера оказались более нагружены);
• продолжение записи сверх указанного в скрипте (перезапись файла более одного раза) не влияет на производительность.

Время чтения (в секундах) файла размером 4Гб для разных дисков:

Жирным отмечены DC модели (остальные — десктопные/ноутбучные); где SATA, а где NVMe, думаю, видно без пояснений.

Мы видим, что по мере случайной записи в файл у самсунга PM981 скорость чтения падала и в итоге упала вдвое (но осталась, правда, достаточно неплохой), а у единственной тошибы в таблице — вовсе в 3.5 раза, фактически сравнявшись с таковой у SATA устройств. С другой стороны, у большинства устройств случайная запись или вовсе не повлияла на производительность, или повлияла незначительно.

Моя интерпретация этих результатов: скорость линейного чтения у SSD действительно может деградировать со временем, однако деградация, вызванная внутренней фрагментацией, не носит совсем уж фатального характера на большинстве дисков (на дисках intel, например, она вовсе незаметна; на дисках samsung если и заметна, всё равно скорость чтения остаётся вполне приемлемой).

Остаётся открытым вопрос деградирует ли скорость чтения со временем по другим причинам (например, из-за износа NAND flash). Могу сказать про тошибу XG5: разницы в поведении между диском, на который по SMART было записано >>150Тб, и новым диском я не заметил ­— или 300-400 перезаписей недостаточно, чтобы износ flash стал заметен, или он вовсе не влияет на производительность SSD.

По поводу падения производительности после случайной записи: у меня как раз на такой тошибе хранится достаточно нагруженная БД mysql размером около 100Гб. Действительно, в полном соответствии с изложенными выше теорией и измерениями, скорость чтения «боевых» таблиц mysql оказалась достаточно низкой (около 600Мб/с), скорость же чтения других крупных файлов с той же файловой системы гораздо выше (>2Гб/с).

Как бороться с внутренней фрагментацией SSD

Если хочется побороть, то можно воспользоваться одним из первых методов дефрагментации: делаем бэкап, удаляем файлы, восстанавливаем из бэкапа. Недостаток этого метода в том, что он достаточно долгий и подразумевает downtime (а через некоторое время данные во флеш-памяти снова окажутся фрагментированными и всё придётся повторять сначала). Так что проще или смириться, или выбирать диски, которые не подвержены этой проблеме. Придумал относительно быстрый способ избавиться от внутренней (и только от внутренней) фрагментации SSD:
sync fsfreeze -f /mountpoint dd if=/dev/nvme0n1p2 of=/dev/nvme0n1p2 bs=512M iflag=direct oflag=direct status=progress fsfreeze -u /mountpoint
Его можно запустить на «живой» системе без размонтирования ФС и остановки сервисов. Он тоже может привести к некоторому простою из-за замораживания ФС, но при желании можно разбить его на несколько итераций, чтобы уменьшить время, на которое замораживается ввод-вывод. Есть ещё одно «но»: я не уверен на 100%, что все SSD правильно обрабатывают ситуацию «пишем нули в область, для которой до этого делали TRIM» (то есть с точки зрения накопителя области ФС, на которые ранее делали TRIM, могут теперь считаться не свободными, а занятыми данными). В целом, рекомендация «забить смириться или выбирать диски» остаётся в силе.

Резюме: дефрагментация может быть полезна для некоторых SSD, однако не совсем такая (совсем не такая?) как для HDD. Нам важно не только то, что файл расположен в непрерывной цепочке секторов, но и то, что запись в эти секторы шла последовательно.

P.S. был бы благодарен, если бы читатели запустили скрипт у себя и привели цифры для своих SSD, так как моя выборка накопителей достаточно однобокая.