Я даже стал удивляться, когда люди мышкой тыкают на ярлыки в рабочем столе, сам то только клаву юзаю и 70% времени консось

Попутно стоит сказать и о том, что в Samsung 860 EVO разработчики починили обработку асинхронной команды TRIM. Такой её вариант используется в Linux, и прошлая серия накопителей Samsung имела досадную ошибку в реализации данной команды, из-за которой возникала опасность потери данных. По этой причине серия 850 EVO была занесена в чёрный список, и поддержка TRIM в Linux для неё деактивировалась. Теперь же проблема исправлена, асинхронный TRIM работает, и деградация производительности в Linux накопителям серии Samsung 860 EVO не грозит.

Кажись и правда что с трим, сломался он у тебя в ядре

Значит теперь я буду говорить, что купил диск из-за высокого интеллекта, а не по рандому

Я сейчас на 5.11

Но он, вроде, теперь EOL

Просто ахуенно, что то чинят в ядре а оно хз как работает и вообще работает, классика

Мб тебе стоит прошивку ссд обновить?

Прыщепроблемы прыщепроблемушки

? Прошивка на диске?

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

Угу, в тредах пишут что на ссд нужно апдейтить прошивку

Пошёл чекну

Вроде fwupd может обновлять самсунги

Получаешь видюху
а
У неё не тот Pcie разьём

fidelityfx cas  стоит ли юзать?

Выглядит это так (проверено для ядра Linux 5.12). На свежеинсталлированной системе запускается скрипт, который в цикле создаёт в домашней директории файлы с определёнными именами, записывает в них данные по определённым смещениям и затем удаляет эти файлы. Через минуту работы этого скрипта ничего необычного не происходит. Через пять минут порция занятого места на разделе слегка увеличивается. Через два-три часа она достигает 50% (при начальном значении 15%). А после пяти-шести часов работы скрипт валится с ошибкой "нет свободного места на разделе". После этого вы уже не в состоянии записать на ваш раздел даже 4К файл.

Происходит интересная ситуация: вы ничего на раздел в итоге не записали, а всё свободное место (порядка 85%) куда-то улетучилось. Анализ раздела, подвергнутого такой атаке, покажет множество узлов дерева, содержащих всего один айтем (объект, снабженный ключом), размером несколько байт. То есть, контент, который ранее занимал 15% дискового пространства оказался равномерно "размазанным" на весь раздел так, что новый файл записать уже некуда, ибо его ключ больше всех существующих, а свободные блоки на разделе закончились.

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