Использует ли SSD диск для выравнивания износа не размеченую область?

Ну, например, Самсунг при разметке диска своей утилитой под виндой предлагает оставить 10% неразмеченным, как раз для wear leveling. Насколько уж это соответствует реальности — другой вопрос. И вряд ли это можно мониторить со стороны файловой системы.

Сделай раздел, отформатируй, ничего на него не пиши. Запусти трим. Тоже самое будет по износу. Да даже если оставлять свободное место и регулярно трим запускать - будет тоже самое

И вряд ли это можно мониторить со стороны файловой системы.

Можно конечно сделать еще один бэкап неразмеченной области диска в другой файл и сравнить их, но это лишняя запись целых 17Гб. Наверняка есть вариант проще, ну хоть скрипт какой написать. Взял сектор с диска, взял столько же байт из файла, сравнил, берем следующий сектор…

Сделай раздел, отформатируй, ничего на него не пиши. Запусти трим. Тоже самое будет по износу. Да даже если оставлять свободное место и регулярно трим запускать - будет тоже самое

Я про износ ничего не писал. Я спрашивал останется ли неизменной информация в не размеченой области диска.

Ему не важно что ты размечаешь, он тебе даёт просто плоский массив секторов. Всё что ты записал - сохраняется до тех пор пока не запишешь в тот же сектор новые данные или не сделаешь ему trim. Для выравнивания износа соответственно используются все те сектора, в которые с момента последнего trim не было записи, опять же не важно в каком они разделе и в разделе ли вообще.

Накопитель ничего не знает о структуре информации, которая на него записана. Ему всё равно, какой тип разметки Вы используете - MBR, или GPT. Тем более он ничего не знает о файловых системах. Ему вообще всё равно какая именно информация на нём лежит. Ему лишь важно какие ячейки отмечены пустыми, а какие - нет. При использовании Secure Erase, команд blkdiscard, или fstrim контроллеру накопителя отправляется команда очистки выбранных групп ячеек. То же самое, делают программы форматирования в большинство файловых систем (но это зависит от конкретной программы). Контроллер накопителя запоминает, что ячейки с указанными адресами пусты. Если после этого, в любую из таких ячеек будет записана любая информация, такая ячейка уже не будет считаться пустой, и информация будет сохранятся до тех пор, пока не будет перезаписана другой, либо пока ячейка снова не будет отмечена пустой.

Считать содержимое выбранного участка накопителя можно с помощью всё той же команды dd. Параметр skip Вам в помощь. Дальше со считанным содержимым можете творить всё что угодно: записывать в файл, сравнивать с содержимым другого файла, подсчитывать/проверять контрольную сумму этого содержимого, etc.

Создал я тему по даному вопросу на форуме Debian, но там никто мне толком ничего не ответил.

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

Для выравнивания износа соответственно используются все те сектора, в которые с момента последнего trim не было записи, опять же не важно в каком они разделе и в разделе ли вообще.

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

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

Система видит лишь то, с чем работает. Неразмеченные области её не интересуют. Так что если SSD был в эксплуатации и на него что-то писали и стирали без TRIM на всём пространстве, то последующая переразметка носителя и оставление «свободной» области выведет её из работы не только из-под операционной системы, но и из-под контроля износа ячеек SSD. Таким образом эта область окажется просто потерянной, а её ячейки неиспользуемыми.

Считать содержимое выбранного участка накопителя можно с помощью всё той же команды dd. Параметр skip Вам в помощь. Дальше со считанным содержимым можете творить всё что угодно: записывать в файл, сравнивать с содержимым другого файла, подсчитывать/проверять контрольную сумму этого содержимого, etc.

Насчет контрольной суммы не подумал, спасибо.
Сделал так:

Контрольная сумма совпадает, значит данные пока что остались неизменны.

А в случае вот такой команды:
zzplex@Debian:~$ sudo dd if=/dev/sda skip=206848 bs=512 count=36880384 status=progress | md5sum
происходит ли какая нибудь запись на диск во временный файл или происходит только чтение и данные сразу передаются команде md5sum для подсчета контрольной суммы? Это я так для самообразования.

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

Еще пока да. Человек пять постоянных там есть.

Система видит лишь то, с чем работает. Неразмеченные области её не интересуют.

Т.е. получается, то что советуют некоторые оставлять часть диска неразмеченым, просто не имеет смысла? Или для линукс не имеет смысла, а для другой ОС может имеет смысл.

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

SSD понятия не имеет о таблице разделов. Всё что для него существует - это пронумерованные сектора по 512/2048 байт.

Просто SSD в отличии от HDD имеет не только команды write и read, но ещё и discard. После discard данные сектора теряются, а сам он может быть использован по усмотрению SSD (в том числе для выравнивания износа). При удалении файла ОС с поддержкой SSD должна выполнить discard для всех его секторов. При форматировании обычно происходит discard всех секторов раздела, потому что мало ли что там лежало.

Так вот, для неразмеченной области discard вызвать просто некому (драйвер ФС не опрерирует этими секторами). Так что если там что-то оставить, то оно будет там лежать нетронутым.

Некоторые люди рекомендуют оставлять часть SSD неразмеченным (при этом очень важно туда ничего не писать, а для того что уже было записанно вызвать discard руками, иначе волшебство не сработает), чтобы было невозможно заполнить данными 100% секторов (потому что просто в ФС место кончится раньше). Также старые ОС и ФС могут не уметь вызывать discard и, как следствие, не освобождать сектора, так что свободные 10% чуть-чуть улучшат ситуацию.

Однако, современные ОС и ФС умеют использовать discard, а ФС в штатном режиме работы ОС никогда не заполняется на 100% (потому что при отсутствии свободного места сломается много других вещей в ОС, плюс на том же Linux есть резервирование 5% пространства из коробки для root).

Просто SSD в отличии от HDD имеет не только команды write и read, но ещё и discard. После discard данные сектора теряются, а сам он может быть использован по усмотрению SSD (в том числе для выравнивания износа). При удалении файла ОС с поддержкой SSD должна выполнить discard для всех его секторов. При форматировании обычно происходит discard всех секторов раздела, потому что мало ли что там лежало.

Спасибо вам большое)) После вашего сообщения у меня в голове все сраслось и все стало понятно. Очень доходчиво объяснили.

оставлять часть диска неразмеченым, просто не имеет смысла?

Именно. Над неразмеченной областью теряется контроль.

Если SSD используется в RAID, то имеет какой-то смысл оставить часть пространства для получения целого числа «цилиндров» в размеченной области, чтобы последующие (дополняющие или замещающие его) устройства гарантированно влезли в контролируемый RAID объём. Но это должно делаться с минимальными потерями полезного пространства.

Важно помнить, что наличие TRIM необходимо лишь для ускорения записи данных на ранее занятые и освобождённые ячейки флэша.

Без TRIM тоже можно обходиться, но при этом контроллер SSD должен подготовить ячейки для записи в момент обращения к ним со стороны операционной системы, что замедляет процесс записи и влияет на степень износа. ФС, если не принимают во внимание работу с флэш, стараются в первую очередь задействовать «быстрые» сектора, находящиеся в начале адресного пространства накопителя. Износ их ячеек самый большой, если данные интенсивно перезаписываются. TRIM же заранее «обезличивает» освобождаемые ячейки, формируя из них пул готовых к записи, внося коррективы в таблицу адресации контроллера.

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

Но можно и вручную отправить именно номера секторов, хоть на разделе, хоть на неразмеченной области (как - не помню).

Но можно и вручную отправить именно номера секторов, хоть на разделе, хоть на неразмеченной области (как - не помню).

blkdiscard

происходит ли какая нибудь запись на диск во временный файл или происходит только чтение и данные сразу передаются команде md5sum для подсчета контрольной суммы?

Pipe передаёт данные от одной программы, другой, когда готовы и источник, и приёмник. Это происходит для каждого байта, передаваемого по каналу. Если источник пытается записать в канал очередной байт, а приёмник ещё не готов его прочитать, то источнику приходится ждать, когда будет готов приёмник. Если приёмник готов к чтению, но не готов источник, то придётся ждать приёмнику.

Утилита dd проста как топор. Чтение происходит блоками (в данном случае, это 512 байт). После чтения, dd пытается записать содержимое блока в файл-приёмник, а если он не указан, то в stdout. В данном случае, stdout перенаправлен в stdin утилиты md5sum. Пока считанный блок не будет полностью записан, dd не приступит к чтению следующего. Эффекты этого можно наблюдать, играясь с размерами блоков, и подставляя приёмники с различной скоростью обработки входящих данных. Например /dev/null принимает данные быстрее, чем md5sum, а sha512sum - медленнее.

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

Контрольная сумма совпадает, значит данные пока что остались неизменны.

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

Т.е. получается, то что советуют некоторые оставлять часть диска неразмеченым, просто не имеет смысла?

Это имеет смысл для продления жизни накопителя, и ускорения его работы. Естественно перед оставлением такой области, следует либо стереть все данные с накопителя, либо освободить её уже после разметки, воспользовавшись blkdiscard. В случае нормального «домашнего» использования, особенно с консьюмерскими ssd, можете не заморачиваться. Тема over-provisioning хорошо раскрыта в этой статье.

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

То, что я читал про ssd-диски скорее подтверждает эту теорию чем опровергает. Вот вроде как должен, но способа проверить нету. И ещё важно: если в тех ячейках будет лежать какая то инфа и никто не скажет ftl-блоку что там пусто - наверное он не будет использовать эту область. За это отвечает команда trim, но я не знаю как это работает и работет ли вообще для областей вне ФС.

И еще один маленький вопросик, достаточно ли в системе закрыть браузер, торрент, всякие месенджеры и выключить журналирование чтобы можно было сделать бэкап прямо в системе, что бы система в процессе копирования не внесла каких либо изменений на диск?

Собственно никакой катастрофы не случится, если ты сделаешь бэкап ничего из этого не закрывая. Я так уже лет 5 наверное делаю бэкапы на живую через tar (со сжатием и отправкой далее по хрону на перепаковку в хранилище zbackup). Торрент-клиент в любом случае сможет проверить данные если что, всякий мелкий софт вроде почтовика, мессенджеров и rss-читалки отлично восстанавливается из таких бэкапов, восстанавливать браузер не пробовал - ещё не падало (или там есть своя система контроля целостности баз). Насчёт образов виртуалок - вот тут осторожнее, на живую не пробовал.

А можно пару вопросов: делается ли trim для пустого места своп-разделов автоматически и если нет, то как сделать его принудительно?

А можно пару вопросов: делается ли trim для пустого места своп-разделов автоматически и если нет, то как сделать его принудительно?

-d, --discard[=policy]
	Enable swap discards, if the swap backing device supports the discard or trim operation. This may improve performance on some Solid State Devices, but often it does not. The option allows one to select between two available swap discard policies:

	--discard=once
		to perform a single-time discard operation for the whole swap area at swapon; or

	--discard=pages
		to asynchronously discard freed swap pages before they are available for reuse.

	If no policy is selected, the default behavior is to enable both discard types. The /etc/fstab mount options discard, discard=once, or discard=pages may also be used to enable discard flags.

Источник: man swapon

То, что я читал про ssd-диски скорее подтверждает эту теорию чем опровергает. Вот вроде как должен, но способа проверить нету. И ещё важно: если в тех ячейках будет лежать какая то инфа и никто не скажет ftl-блоку что там пусто - наверное он не будет использовать эту область. За это отвечает команда trim, но я не знаю как это работает и работет ли вообще для областей вне ФС.

Насчет этого я лично все понял прочитав сообщения, все доходчиво и понятно: KivApple ★★★★★ (01.01.23 16:36:36 KRAT)
iZEN ★★★★★ (01.01.23 15:27:21 KRAT)
QsUPt7S (01.01.23 20:05:25 KRAT)

Собственно никакой катастрофы не случится, если ты сделаешь бэкап ничего из этого не закрывая.

Я усомнился не просто так. Передтем как все сделать я решил потренероваться на другом диске. Есть у меня HHD c плохим смартом и очень большим колличеством плохих ячеек но бэдов нет. Перенес все разделы на него и сделал все прямо на ноутбуке в системе. При этом был включен браузер, играло радио с плагина KDE Plasma. Скопировал бэкап в не размеченую область диска, и скопировал правленый бэкап нулевого сектора диска, где вместо системного раздела прописаны 16 байт от не размеченой области. А потом позвала жена новый год встречать. Я все бросил и бук перезагружать не стал. Вернулся через некоторое время, перезагрузил ноутбук. Он загрузился, но что то там было написано при загрузке чего раньше не было. Я решил прочитать и перезагрузил еще раз, но со второго раза он не загрузился предложил выполнить какуюто команду. Я загуглил, это оказалась проверка диска. Запустил, было много ошибок, и запомнилось что много было связано с Firefox в домашнем разделе. После их исправления ноутбук опять загрузился. Ну собственноя я не знаю из за чего это было, из за того что я на рабочей системе сделал бэкап или из за того что подменил mbr, а перезагружаться не стал. Т.е. система загрузилась с одного раздела, а я сделал так что таблице разделов прописан другой раздел. И еще и комп перезагружать не стал.

Ага, спасибо. Кажется ничего делать не требуется.

Скопировал бэкап в не размеченую область диска, и скопировал правленый бэкап нулевого сектора диска, где вместо системного раздела прописаны 16 байт от не размеченой области.

Я правильно понял, что ты бэкапил блочное устройство через dd с «живой» файловой системой на нём? Ну да, разумеется, в процессе ФС была слегка (или не слегка) повреждена.

Я же бэкаплю файлы на ФС, во первых никаких повреждений не происходит, а во вторых крайне резко сокращается вероятность изменения за время чтения.

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

Я правильно понял, что ты бэкапил блочное устройство через dd с «живой» файловой системой на нём?

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

перспектива сделать бэкап с «живой» файловой системой как вы выразились так и манит.

Это называется «снапшот». И для того чтобы бэкап был консистентным, ведь фс то у нас живая и блоки изменяются и записываются прямо во время и в процессе бэкапа, требуются дополнительные действия — нужно перед бэкапом сбросить на диск кэши и буферы, «заморозить» запись, пусть например блоки на запись в кэше накапливаются, пока бэкап не завершится и блочное устройство не разморозится, или через COW пишутся в другое место, на другое блочное устройство. После окончания бэкапа их можно будет обратно «объединить».

Это реализовано в LVM2, на уровне блоков, работает с любой ФС или без неё, например для RAW томов БД. А так же это часть функционала btrfs и zfs.

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

Никакой «хитрой» эвристики в dd нет — если пытаемся копировать блок в который в данный момент идет запись — получаем в зависимости от ключей и дефолтных настроек либо ошибку копирования, либо «битый» блок, то бишь образ тоже будет «битый», неконсистентный. Аналогично при попытке ФС писать в блок который в данный момент копируется — получаем «битый» файл, то бишь повреждённую ФС.

Ты по сути переизобретаешь снапшоты, не нужно, они уже изобретены. И ФС у тебя побилась потому что запись в процессе копирования не блокировалась. И кстати копия тоже неконсистентна и повреждена, по той же причине.

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

Так что в качестве бэкапа настолько грубый подход не годится, обессмысливает саму идею.

Кое кто пользуется Clonezilla для копирования образа раздела в файл, а потом если что из этого образа восстанавливают раздел. А я то по сути не тоже самое сделал? Только для восстановления системы не надо из файла ничего восстанавливать, все уже на диске.

Это реализовано в LVM2

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

Кое кто пользуется Clonezilla для копирования образа раздела в файл, а потом если что из этого образа восстанавливают раздел. А я то по сути не тоже самое сделал? Только для восстановления системы не надо из файла ничего восстанавливать, все уже на диске.

Не совсем, я же выше объяснил почему. Недостаточно доходчиво видимо? Представь себе что кто то взялся снимать геометрию со стула на котором ты сидишь и ёрзаешь, от чего стул постоянно качается и изгибается. Так что этот «кто то» никак не может точно геометрию снять, потому что в процессе измерения она постоянно меняется. И чтобы это прекратить достаточно попросить тебя замереть на минуточку и перестать ёрзать. Но вы с этим «кем то» никак не общаетесь.

LVM2 умеет «попросить не ёрзать», точнее она умеет сделать так чтобы ёрзанье не мешало, перенаправляя запись в другое «блочное устройство» (временный том снапшота). BTRFS и ZFS тоже так делать умеют, к тому же они сами по себе FS, так что у них нет необходимости «обманывать» слой FS.

только уже из-под другой системы, но все той же командой dd

Это всегда пожалуйста, главное чтобы в процессе копирования не производилась запись в то блочное устройство которое ты копируешь. Если у тебя система стартовала с другого диска\раздела, и копируемое блочное устройство не смонтировано, или ФС на нём смонтирована в режиме «только для чтения» — всё будет в порядке.

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

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

Это странно, сам по себе LVM2 не добавляет «накладных расходов» при работе FS. Конечно подтормаживание возможно в процессе снятия копии с тома после снапшота. Так же при обратном «сливании» снапшота с основным томом, особенно если это частая процедура, растёт фрагментация. Для HDD и в особенности для баз данных это нехорошо. Есть дефрагментатор для LVM2, но я им никогда не пользовался. Для SSD это все проблем не составляет вообще, это HDD заморочки.

Ну я так и подумал, поэтому и спрашивал в первом сообщении как бы что отключить, чтобы информация на диске не изменялась в процессе копирования.

Вообще у mount есть ключ remount, и можно перемонтировать FS в режиме RO (read only). Но здесь возникают другие трудности. ФС ты в RO перевёл, но запущенные программы об этом не уведомлены и желают продолжать писать, например логи, промежуточные сохранения и т.п. И получают отлуп от ядра, так как FS в RO. И ругаются в консоль, и глючат, и выкидывают страшные таблички, если они графические, так как в лог ругнуться они не могут, запись запрещена. Поэтому технически remount в RO делает как раз то что тебе нужно, прекращает запись в копируемое тобой блочное устройство на уровне FS, но практически это ломает тебе ОС на время копирования и делает её малофункциональной. Так что этим никто не пользуется, и либо загружаются с другой ОС и копируют, либо используют снапшоты LVM2\BTRFS\ZFS, либо бэкапятся уровнем выше, на уровне файлов, а не блоков.

Есть ещё всякие коммерческие системы бэкапа на центральные серверы, которые имеют свои модули ядра в составе «клиента», взаимодействующие с ФС и прозрачно для программ «морозящие» запись, но во первых они привязаны к конкретным версиям ядра, конкретным коммерческим поддерживаемым дистрибутивам, конкретным FS, а во вторых это по сути те же бэкапы со снапшотами, только платные.

Вообще у mount есть ключ remount, и можно перемонтировать FS в режиме RO (read only). Но здесь возникают другие трудности

Трудности в том что этот ключ почти никогда не работает. Или я не нашёл как его применить принудительно. За исключением случая remount-ro on error, который работает всегда.

Тебе уже ответили, но я добавлю: на мой взгляд это бесполезно. Свап-раздел обычно занимает весьма маленькую долю объёма диска, и хорошо локализованную (всмысле, он всегда на одних и тех же секторах), заметного влияния на долговечность диска trim-ы на нём не окажут. Ну если только всё остальное место диска не забито под завязку.

Ага, согласен. Я так понимаю от используемой FS тоже многое зависит. ext3 ЕМНИП мне удавалось принудительно в RO перемонтировать, а с ext4 оно ругалось, а при форсировании случался OOPS. Это скорее всего потому что иначе как remount-ro on error оно и не используется никем уже сто лет.

fstrim

А если LUKS?

Не совсем, я же выше объяснил почему. Недостаточно доходчиво видимо?

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

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

Clonezill`ой я не пользовался, а только почитал, что можно скачать образ диска, сделать загрузочную флешку, загрузиться с нее и скопировать образ системного раздела в файл. А если у меня уже есть образ Live CD Debian на флешке, то я могу сделать тоже самое загрузившись с него комадой dd через терминал. Поэтому я и написал что по сути это одно и тоже. Просто я подцепил SSD диск к другому компу, чтобы не искать флешку.

Это хорошо, просто мне показалось что вы не понимаете почему копировать блочное устройство на которое ведётся запись одновременно опасно для работающей ОС и бессмысленно для создания бэкапа. Теперь я вижу что вы всё поняли и сделали правильно, просто я невнимательно читал.

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

Ага, обычно... Правда у меня привычка выделять под своп либо ~10-20% ssd, либо я отдал весь ссд чисто под своп, даже без разметки. А ещё я не уверен что подсистема разбрасывает данные по всему пространству а не кучкует их в начале. Но, как подсказали выше, trim для свопа активируется по умолчанию.

А если LUKS?

Я шифрованием не пользуюсь, но быстрый просмотр мануалов говорит, что в файле crypttab можно задать опцию монтирования discard, а cryptsetup open поддерживает опцию --allow-discards:

--allow-discards
	Allow the use of discard (TRIM) requests for the device. This is also not supported for LUKS2 devices with data integrity protection.

	WARNING: This command can have a negative security impact because it can make filesystem-level operations visible on the physical device. For example, information leaking filesystem type, used space, etc. may be extractable from the physical device if the discarded blocks can be located later. If in doubt, do not use it.

	A kernel version of 3.1 or later is needed. For earlier kernels, this option is ignored.