>>0454

>Найди в спецификации требование к диску при получении этой команды зависать на минуты или часы, обнуляя блоки, пока система терпеливо ждёт. Нету ни в одном варианте ничего «немедленного», это только указание на то, что элементы свободны, и диск в дальнейшем волен с ними поступать так, как считает нужным.

Ну ты просто гадаешь, как и я сначала. Я вот немножко почитал еще вчера. Буквально минут 25. И уже начал понимать что-то. Думал, в треде хоть тыкнут носом, что и где почитать. А вы тут сами манюни.

По сути есть два варианта отправить команду на трим: fstrim и blkdiscard.
fstrim работает со смонтированной файловой системой. И отправляет список удаленных блоков.
blkdiscard может отправлять трим не смонтированному устройству, как блочному устройству, а не файловой системе.

Если первый имеет смысл для регулярного выполнения. То второй для однократной очистки для подготовки диска к разметке и новому использованию (мы можем просто разметить и отформатировать SSD заново. При этом вроде бы blkdiscard выполняется автоматом на протяжении всего объема создаваемого тома, если делать это из под линуксовых парт менеджеров, но это не точно).
И тот, и другой, позволяют указывать кусок на ssd, который надо очистить. Но первый всё равно пошлёт только те блоки, которые удалены из таблицы файловой системы. А второй сбросит все блоки на устройстве подряд (от начачаа до конца или в указанном диапазоне). А в случае опции blkdiscard -secure, если она поддерживается на SSD, будут сброшены даже какие-то резервные копии блоков чистильщика мусора. Это типа для безопасного стирания данных.
При любом варианте, оттримленные области диска будут возвращать нули на всех современных SSD, минимум последних трех лет. Называется это Deterministic read ZEROs after TRIM.

Запускается очистка мусора через fstrim и blkdiscard прямо сейчас, а не в фоне, когда захочет прошивка ssd.
При выполнении команды ssd переходит в статус busy (горит индикатор активности диска на ПК). И чем реже запускал команду, тем он надольше повисает. Если исполнить fstrim на SSD, где прошло очень много данных. А до и после этого произвести прямое клонирование. То после трим, т.к. будет больше нулей на протяжении всего диска, то сжатый снимок будет весить меньше. Что говорит о том, что fstrim сработал немедленно, а не когда SSD захотелось.

А значит вместо фоновой функции ITGC (Idle Time Garbage Collection ) запускается функция очистки по запросу GC (Garbage Collection).
Певрое это то, что диск делает сам, когда курит без дела. Второе для исполнения по требованию.

Подефолту fstrim работает на еженедельную отпраку trim (а не ежедневную или при каком-то объеме удалённых данных), именно потому, что это лишь подстраховка - дополнение к ITGC. Например, если ssd редко бывает свободным и потому не занимается тримингом сам. А нам надо хоть иногда провоцировать сборщика мусора принудительно даже ценой подвисания ввода/вывода. Так как эти подвисания были проблемой для серверов, придумали как раз добавить в sata 3.1 очередь на трим именно потому, что исполняется-то команда сборки мусора немедленно. Если бы диск занимался очисткой только в фоне, на кой хуй нужно добавлять в sata протокол отдельным параметром очередь? -Если бы у нас априори диск всегда ждал idle состояния.

Т.к. очередь в винде не была реализована, а на линукс всем похер, то отправка жирного массива удаленных пакетов вызывала глюки и потерю данных на большом списке ssd из-за кривой прошивки, в частности самсунгах. И в линуксах такие SSD вносили в блэклист, чтобы вместо очереди работал способ с немедленным исполнением, пусть это и вешало на какое-то время i/o. -Вернулись к истокам.

Очередь доступна только, начиная с sata 3.1. На 3.0 - нет. И я так понял, что материнка тоже должна быть sata 3.1 или 3.2. Хотя точного ответа нет, должна ли мать тоже быть свежей. Вот например тут никто не знает: https://superuser.com/questions/1566084/does-the-queued-trim-support-in-sata-3-1-require-support-from-the-sata-controlle Гугл ничо не выдаёт.

Часто trim делать не рекомендуется, т.к. это тратит ресурс дисков. Потому что растут циклы перезаписи. Ну логично, что лучше иметь больше свободного объема для записи без потери скорости, чем постоянно уплотнять блоки на мелком ссд и тратить лишшние циклы записи. Поэтому в том числе подефолту трим даже не ежедневный, а раз в неделю. -В дополнение к тому соображению, что на типичном пк все таки еще и успевает отработать фоновый ITGC, и лишний прогон нам не требуется.

На hdd добавление пароля доступа к диску можно использовать для мгновенного форматирования. То есть, на диске создается ключ, все данные прогоняются через шифрование эти ключом. Когда нужно моментально очистить все данные с hdd без мгногочасовой записи нулей в каждый сектор, просто удаляем пароль=ключ. И на hdd данные останутся, но без ключа будут бесполезны, хоть зачитайся (хотя коммерческое шифрование это хуйня - 100% ключи слабые или отданы кому надо, но не суть).

На ssd тоже есть блокировка паролем=ключом. Но не имеет смысла ставить ключ уже после того, как данные были записаны, как и в случае с hdd. ATA Secure Erase это для ssd устаревший вариант, т.к. blkdiscard -secure сделает нули во всем диске (без их фактическое записи) за несколько секунд, что на hdd никак невозможно. Поэтому установка ключа - костыль для быстрой очистки HDD. А На SSD не нужен.

Ещё одно отличие blkdiscard от fstrim, что он может увеличить скорость ssd на какое-то время. За счет того, что будут сброшены те блоки, которые через fstrim не отправлялись. Вроде, как если данные не удалены, а изменены, то их блоки не подпадают под отправку через fstrim. Когда таких накопится много, начнет страдать скорость записи. Берем ssd, сливаем все данные в другое место, выполняем blkdiscard -secure, заливаем обратно. -Это некоторым из интернетов реально помогало вернуть скорость. Можно считать такое шаманство методом обслуживания, как смена термопасты.