можно ли проводить дефрагментацию ssd диска

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

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

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

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

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

Спойлер: проблема присутствует (существенно влияет на производительность) только на одной из попавшихся под руки моделей (и та позиционируется производителем не как datacenter, а как десктопная/ноутбучная).

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

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

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

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

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

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

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

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

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

Из внешних зависимостей только fio ; путь к exe-файлу и временному файлу указывается в первых строчках скрипта.

Получил следующие результаты:

Время чтения (в секундах) файла размером 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Гб/с).

Если хочется побороть, то можно воспользоваться одним из первых методов дефрагментации: делаем бэкап, удаляем файлы, восстанавливаем из бэкапа. Недостаток этого метода в том, что он достаточно долгий и подразумевает downtime (а через некоторое время данные во флеш-памяти снова окажутся фрагментированными и всё придётся повторять сначала). Так что проще или смириться, или выбирать диски, которые не подвержены этой проблеме.
Придумал относительно быстрый способ избавиться от внутренней (и только от внутренней) фрагментации SSD:

Не должно приводить к потере данных, но я не тестировал на боевых системах, ничего не гарантирую!
Есть ещё одно «но»: я не уверен на 100%, что все SSD правильно обрабатывают ситуацию «пишем нули в область, для которой до этого делали TRIM» (то есть с точки зрения накопителя области ФС, на которые ранее делали TRIM, могут теперь считаться не свободными, а занятыми данными).
В целом, рекомендация « забить смириться или выбирать диски» остаётся в силе.

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

Источник

Есть ли смысл дефрагментировать SSD?

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

Дефрагментация SSD: есть ли в этом смысл?

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

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

Windows: отключение дефрагментации SSD

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

Источник

Как ускорить работу и продлить жизнь SSD — правда и мифы

Как определить ресурс накопителя

Ресурс SSD можно понять по гарантированному объему записи (TBW), указанному в характеристиках накопителя. Так, для Samsung 850 EVO на 256 гигабайт — 75 TBW, для HP S700 Pro на 512 гигабайт — 340 TBW. Обратите внимание, что у более емких накопителей ресурс тоже больше. Если вы ориентируетесь на этот параметр при выборе SSD, сравнивайте версии одного объема.

Утилита CrystalDiskInfo покажет, сколько данных уже было записано на диск. Смотрите параметр «Всего хост-записей». В нашем примере — 26 065 гигабайт. То есть примерно 26 терабайт из 75.

Кроме того, можно посчитать среднее количество записываемых данных в месяц, если вы помните, когда покупали и начали пользоваться диском. В нашем случае диск находится в системе 4 года и 1 месяц: 26 065 / 49 = 532 гигабайта в месяц. Несложно подсчитать, что при таком расходе диска хватит еще более чем на 6 лет. Диск работал без какой-либо оптимизации со стороны пользователя.

Важно также проверить максимальное количество циклов перезаписи (P/E Cycles). Нужно открыть параметры S.M.A.R.T. (есть в CrystalDiskInfo) и найти строку Wear Leveling Count. В нашем случае диск изношен на 6%, а число циклов перезаписи составляет 127. Делим количество циклов (127) на процент износа (6) и умножаем на 100. Получается 2117, но это приблизительное число.

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

Обновление прошивки

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

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

Оптимизация и перенос программ на HDD

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

Впрочем, переносить кэш браузера на жесткий диск не стоит — вы лишь замедлите работу программы. Задумываться об оптимизации стоит, если у вас очень большие ежедневные объемы записи данных.

Многочисленные советы из интернета о переносе программ на другой диск тоже сомнительные. Но если у вас диск малого объема, например, 128 Гб, то смысл есть. Программы, которыми вы редко пользуетесь или которые не требуют быстрого накопителя, позволят сэкономить место.

Функция TRIM

Команда TRIM удаляет данные с неиспользуемых ячеек памяти, чтобы при последующей записи не тратить время на их очистку. Грубо говоря, система подготавливает блоки для повторного использования.

В Windows 10, 8 и 7 функция включена по умолчанию (для XP и Vista нужен специальный софт), но лучше проверить ее работу. Откройте командную строку от имени администратора и введите fsutil behavior query disabledeletenotify. Если в двух строках стоит значение 0, то функция TRIM включена.

Также нелишним будет проверить, верно ли определяется SSD в вашей системе. Зайдите в свойства накопителя через правый клик в проводнике. Выберите вкладку «Сервис» и нажмите на «Оптимизировать». В открывшемся окне будет список накопителей с указанием их типа. Если диск SSD определяется как жесткий диск, это нужно исправить. Выполните команду winsat diskformal в командной строке. Также может помочь переустановка драйвера.

Включить TRIM вручную можно командами:

Дефрагментация

Твердотельные накопители не нуждаются в дефрагментации. Однако и отключать ее, следуя советам из сети, не нужно. Дело в том, что Windows и так знает, что в системе установлен SSD, поэтому не будет его дефрагментировать. Таким образом, отключая оптимизацию (именно так этот пункт и называется в Windows 10) по расписанию, вы ничего не добьетесь.

Файл подкачки

Идея перенести файл подкачки на HDD или вовсе его отключить не лишена здравого смысла. Впрочем, вопрос все равно довольно спорный. С одной стороны, отсутствие pagefile.sys может заметно сэкономить свободное место на SSD и уменьшить его износ. С другой — сколько бы ни было оперативной памяти, в определенный момент ее может не хватить. Проблемы возникают даже при наличии 64 гигабайт оперативки, так как аппетиты программ не всегда предсказуемы.

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

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

Режим гибернации

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

Защита системы

Функция «Защита системы» создает точки восстановления системы, к которым можно вернуться в случае сбоя. Точки восстановления занимают определенное место на диске. В нашем случае — 6,36 ГБ. Если хотите сэкономить место на накопителе, отключите восстановление системы. Но вы лишитесь возможности восстановить систему в случае сбоя.

Наберите в поиске «Восстановление» и в открывшемся окне кликните на ссылку «Настройка восстановления системы». Далее нажмите на кнопку «Настроить» и отключите защиту системы.

Свободный объем и Over Provisioning

В связи с особенностями работы SSD рекомендуется оставлять на нем 10−15% свободного пространства. Следить за этим можно вручную или с помощью фирменной утилиты (если она есть).

Так, в Samsung Magician доступна функция Over Provisioning, которая позволяет зарезервировать место в автоматическом режиме. Можно выбрать объем вручную, но лучше предоставить право выбора системе.

Режим AHCI

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

Зайдите в «Диспетчер устройств» и найдите строку «Контроллеры IDE ATA/ATAPI». Если в выпадающем списке значится AHCI, то все в порядке.

Источник

Дефрагментация SSD: так она есть или нет?

В своё время относительно дисков SSD существовало устоявшееся мнение о том, как соотносится внедряемая технология «крепко» сидящих чипов (идущая на смену «спиннерам» HDD) к такой незаменимой долгое время и обязательной функции оптимизации диска как Дефрагментация. И мнение это можно было охарактеризовать словосочетанием «НЕ НУЖНО и НЕЛЬЗЯ». С момента приобретения первого своего компьютера каждый пользователь впитал, в том числе, и мысль, что жёсткий диск с каждым байтом записанной на него информации приближается к своей смерти. А в отношении же SSD политика Windows казалась вполне определённой: дефрагментация для SSD отключена по умолчанию. Всё вроде бы сходится. Однако нашлись люди, которые копнули в суть вопроса. Один из IT-блогеров успел заметить, что процесс оптимизации под контролем службы defragsvc чем-то всё-таки с диском занимается. В связи с чем у автора в концовке возник резонный вопрос: а не вредит ли система сама себе? Да чёрт с ним «себе»: SSD-то за свои кровные куплен…

На данный момент наиболее мудрые специалисты уже избегают категоричности в ответе на вопрос «нужна ли оптимизация SSD» в том виде как она есть. Так происходит ли на самом деле дефрагментация SSD?

Пару сведений

Англоязычная Википедия утверждает, что Microsoft Drive Optimizer (она же утилита Оптимизации дисков, она же dfrgui.exe) ранее носившая имя — внимание — Дефрагментация дисков, предназначена для ускорения скорости доступа к диску за счёт реорганизации структуры файлового размещения. Технология разработана для носителей со считывающими головками, и для карт SD, флешек и носителей SSD использована быть не может.

А на самом деле?

Однако, подытоживая «расследования» отдельных пользователей и анализируя ответы технических специалистов самой Microsoft, можно с уверенностью утвердиться в нескольких фактах:

Дефрагментация SSD действительно имеет место быть. Это точно происходит как минимум ЕЖЕМЕСЯЧНО в том случае, когда активирована функция создания теневой копии. Причём Windows делает это нарочито из-за крайне низкой скорости записи на фрагментированных томах SSD. Да — если ещё кто не понял — фрагментация SSD также имеет место быть. А куда от неё денешься-то? И, как и в случае с HDD, пользователь вполне может столкнуться с ситуацией, когда разросшаяся до максимума фрагментация файлов (метаданные уже просто не способны отобразить все фрагменты дефрагментированных данных) на SSD не позволит файл прочитать или записать. А вот здесь, в свою очередь, пользователь сталкивается с проблемой производительности SSD, чьи преимущества перед HDD начинают сходить на нет.

Как же так?

есть смысл проводить оптимизацию пореже

В Windows 10, в отличие от Windows 7, система отсылает команды TRIM-функции всему диску, пока тот не занят и пользователь не проводит никаких операций с носителем. Это занимает мгновения. И за процесс отвечает запланированная в Планировщике задача под именем ScheduledDefrag. Обнаружить её легко из Проводника, набрав в строке поиска адрес

проникнув, тем самым, через папку с заданиями Tasks в корне директории System32. Кстати, имя скрытой задачи традиционно связано именно с процессом дефрагментации, сбивая с толку приверженцев «теории», что SSD и дефрагментация понятия несовместимые. Тем более смущает Дата изменения файла в его метаданных. У вас SSD? Проверьте-ка:

Дело не в конкретной цифре, а в том, что задача была выполнена. Всё ещё сомневаетесь? Запускаем PowerShell:

Но это всё было бы ничего… Обратите внимание на отчёт об успешной дефрагментации (!) диска:

Проверьте свои диски — была ли дефрагментация SSD носителя у вас? У меня она появлялась регулярно на всех машинах с SSD. И даже чаще чем хотелось бы:

щёлкните, чтобы увеличить

То есть эта та самая дефрагментация SSD, что и на HDD? Некоторые пользователи, как и я сам у себя, отмечали более чем регулярную работу оптимизатора Windows 10 вплоть до версии 2004. Чуть ли не из сеанса в сеанс. То есть с каждым включением компьютера.

Дефрагментация SSD вручную. Нет, пробовать не стоит.

Снова помятуя о статье русскоговорящего блогера, тот продемонстрировал возможность ручного запуска дефрагментации SSD при определённых условиях. Как то:

Но путаться, так до конца. Как мы помним из информатики, простейшая операция Not AND — основа для любых более-менее сложных булевских команд. И диск состоит из бесчисленного числа таких ячеек NAND. HDD, насколько я понимаю, целиком полагается на этот принцип записи информации, который даёт сбой только если оба входящих параметра ВЕРНЫ (TRUE). Так что вполне было бы логичным представить взбесившийся над поверхностью диска HDD шпиндель с головкой. Который носится туда-сюда, сначала нанося на диск информацию, а потом её считывая. У SSD немного не так: шпинделя и спиннер-плиток нет, и работа диска к физическому расположению данных никак не относится. От слова «вообще». Однако любая активность по принципу «записал-прочитал-удалил» по-любому снижает продолжительность его жизни. В том виде, как дефрагментация работает на HDD, она к SSD неприменима.

Так что теперь, любоваться диском что-ли? И что делать-то?

Конечно, глупо было бы давать совет типа «а записывайте-ка на диск поменьше да пореже…». Но делать наспех ничего не нужно. Точно не нужно удалять указанную выше задачу в Планировщике. Не стоит пока исключать SSD из списка обслуживания Оптимизатором. Более того, я бы сразу вам посоветовал отнестись с осторожностью к дальнейшим изысканиям по модификации задачи в Планировщике, которая ещё пару лет назад была очень популярна. Суть её заключается в редактировании строчки дополнительных аргументов указанной выше текстовой версии файла задачи:

Добавление ключей -l (операция TRIM) -h (выполнять с высшим приоритетом)к указанному диску (С: — если SSD не разбит на несколько разделов) должно было решить «проблему» дефрагментации SSD. И ведь это всё на фоне оригинальной статистики собранной с отзывов пользователей блога по поводу как часто была зафиксирована дефрагментация SSD уже на их компьютерах:

По прошествии времени, однако, блогер в той же статье отошёл от категоричности суждений по поводу «явного бага» со стороны Windows, якобы уничтожающего (непреднамеренно, конечно) наши диски SSD. Хотя и предоставил всем страждущим отличный материал для размышлений, утверждая что добивался на фоне всей собранной им статистики каких-либо внятных ответов со стороны портала Microsoft Connect. И, конечно же, ничего не добился. В любом случае точной информации о том, что же конкретно затрагивает дефрагментация SSD, мало. Если честно, то меня лично сильно напрягает именно факт привязки дефрагментации к службе теневого копирования. Последняя, как оказалось, является своеобразным триггером к запуску первой? Windows 10 и так постоянно лишает нас относительно независимых от её серверов вариантов восстановления системы и данных, а тут ещё это… И, к слову, приводимые автором аргументы и доводы на страницах форумов и блогов кажутся более чем обоснованными. Особенно на фоне поверхностных знаний остальных IT блогеров и партизанского (как обычно) молчания со стороны Microsoft.

В общем, вот вам пища к размышлению. И успехов нам всем.

Источник