Слишком долгое завершение работы Alt Linux Workstation K10

[nialiv]

У меня было похоже, только из 30 оставалось 7. Перевёл корень на btrfs со сжатием zstd, и занятое место уменьшилось с 23 ГБ до 10. Можно это сделать, загрузившись с другого Альта.

Сжатие, это понятно, однако, лишние данные ни куда не деваются, они просто заимают меньше места, но требуют дополнительные ресурсы процессора для упаковки и распаковки. Я через это проходил, когда объёмы винчестеров были мизерными и составляли, даже страшно сказать, 40 - 80 мегабайт. Тогда тоже были программы сжатия данных (Stacker, DoubleDisk, DoubleSpace, DriveSpace...), которые в зависимости от алгоритма, сжимали данные в 2 - 20 раз, создавая иллюзию 2 - 20 кратного увеличения объёма, но сжатие значительно отнимало ресурсы процессора и снижало надёжность винчестера, к тому же, такая эффективность была только в случае использования большого количества мелких файлов, а в случае больших и очень больших файлов эффективность утилиты сжатия практически равнялась нулю. Скажем на винчестере в 40 MB "свободного места" могло быть 50 -60 MB , а при потытке записи заархивированного файла, объёмом 1,5 MB выводилось сообщение, что файл не умещается на диске.
Не верю я в такое "сжатие", от "лукавого" всё это.

[Letmein]

при потытке записи заархивированного файла, объёмом 1,5 MB выводилось сообщение, что файл не умещается на диске.

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

значительно отнимало ресурсы процессора

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

и снижало надёжность винчестера

Почему? Использование диска тут наоборот меньше, т.к. меньше объём записи.

[nialiv]

Почему? Использование диска тут наоборот меньше, т.к. меньше объём записи.

Берутся файлы, сжимаются, затем исходные файлы удаляются. Затем, когда они потребуюся сжатые файлы разжимаются записываются на диск, это было так в начале 90-х. Хотя, вполне возможно, что сейчас файлы сжимаются непосредственно из памяти, сразу на диск и наоборот.
Я предпочитаю лучше выделить немного больше места, если это обычный винчестер, а на SSD на каждый раздел в 2 - 3 раза больше требуемого, например, у меня Debian 12 Plasma установлен на SSD, объёмом 120 GB, 8 GB выделил для Swap, остальное разделил "по братски", между корневым и домашним разделами. За около 15 лет активного использования Linux, у меня не было ни одного случая использования раздела Swap. К томуже, я выставил параметр интенсивности использования Swap  равным 10 для HDD и 5 для SSD, командой,

Код: [Выделить]

# sh -c "echo 'vm.swappiness=5' >> /etc/sysctl.d/99-sysctl.conf" для для SSD.
Пока, начиная с версии 10 в Дебиане ни каких проблем не было.

[Letmein]

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

Судя по всему, да.

Btrfs supports transparent file compression.

а на SSD на каждый раздел в 2 - 3 раза больше требуемого

Почему?

[nialiv]

Почему?

Это связано с приципом записи информации на SSD, если на SSD сделать небольшой запас свободного места, как на HDD, то довольно скоро TBW превысит допустимое значение, например для SSD, обёмом 120 GB он составляет 40 TB, или его можно будет полностью перезаписать 333 раза. Поэтому контроллер настроен так, что каждый раз новую информацию записывает в новые блоки. Если, например, для системы использовать 20 GB,
как на обычном HDD (в 6 раз меньше), то количество информации на раздел можно будет записать уже не 40 TB, а 6,7 TB. И ресурс SSD значительно уменьшится. Нынешние операционные системы (особенно Windows) ведут очень интенсивный обмен информацией с накопителем. Если HDD начинает "умирать", пусть не сразу, но становится заметно снижение производительности, "битые" сектора аомечаются буквой "B" и заменяются резервными и в это время можно спасти информацию, переписав её на другой HDD. В случае с SSD, если появляется хотя бы одна "битая" ячейка, накопитель становится просто куском пластика. За свою сисадминскую практику (более 25 лет) я много раз восстанавливал информацию с почти полностью "убитых" HDD, но не было ни одного случая спасения информации ни с одной флешки, а SSD, по сути, большая скоростная флешка, во всяком случае, принцип записи информации на нём тот же. А утилит для восстановления информации с SSD я пока не видел.

[Letmein]

Если, например, для системы использовать 20 GB, как на обычном HDD (в 6 раз меньше), то количество информации на раздел можно будет записать уже не 40 TB, а 6,7 TB.

Почему? Контроллер SSD ведь ничего не знает про разделы. Логично, что писать он будет на самом деле во всему диску. Т.е. не думаю, что здесь так просто можно высчитать, поделив одно на другое.

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

[gosts 87]

Если HDD начинает "умирать", пусть не сразу, но становится заметно снижение производительности, "битые" сектора аомечаются буквой "B" и заменяются резервными и в это время можно спасти информацию, переписав её на другой HDD. В случае с SSD, если появляется хотя бы одна "битая" ячейка, накопитель становится просто куском пластика. За свою сисадминскую практику (более 25 лет) я много раз восстанавливал информацию с почти полностью "убитых" HDD, но не было ни одного случая спасения информации ни с одной флешки

Поэтому предпочитаю старые-добрые "харды"!

[Виктор Дуб]

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

Вы видели живого человека, который не может пользоваться SSD, по причине исчерпанного ресурса записи?!

[Nicom]

Поэтому контроллер настроен так, что каждый раз новую информацию записывает в новые блоки. Если, например, для системы использовать 20 GB,
как на обычном HDD (в 6 раз меньше), то количество информации на раздел можно будет записать уже не 40 TB, а 6,7 TB. И ресурс SSD значительно уменьшится.

Накопитель ничего не знает про разбиение на разделы и файловые системы. Поэтому ваша цифра в 6,7 ТВ некорректна.
За пределами ресурса SSD не превращается в кусок пластика, просто вы лишаетесь гарантии производителя. А SSD продолжает нормально работать, пока не сдохнет контроллер, не "слетит" firmware, или не начнётся "забывание" сохранённой информации. Предел количества записей во флэш память превосходит ресурс раз в 10, почитайте ресурсные тесты.

В случае с SSD, если появляется хотя бы одна "битая" ячейка, накопитель становится просто куском пластика

Неверно. Контроллер точно так же, как и на HDD "ремапит" эту ячейку.

А утилит для восстановления информации с SSD я пока не видел.

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

а SSD, по сути, большая скоростная флешка, во всяком случае, принцип записи информации на нём тот же.

Тоже не верно, принципы записи разные, так как используется разная память, контроллеры и firmware контроллеров.

Поэтому предпочитаю старые-добрые "харды"!

А смысл ограничивать себя в скорости загрузки программ?

Вы видели живого человека, который не может пользоваться SSD, по причине исчерпанного ресурса записи?!

Видел, себя.
SSD на 120ГБ работали в видеорегистраторах на общественном транспорте.
После 3-4 лет постоянной перезаписи, а на такой диск входит примерно 3 дня видео, начинается деградация ячеек, а регистраторы не смотрят SMART.
В итоге накопители, в зависимости от модели, либо переходили в режим "только чтение", либо просто отваливались и не виделись даже на компьютере в bios.

[mrs]

На домашнем сервере бюджетные китайские SSD 120 Гб Ceamere каждые пол года выходят из строя (софтовый рэйд спасает от потери данных). Используются постоянно для перегенерации данных, но точно не скажу, сколько там циклов перезаписи происходит за пол года. Как закончится запас этих ссдэшек, наверное буду брать что-то более долговечное.

[gosts 87]

Вы видели живого человека, который не может пользоваться SSD, по причине исчерпанного ресурса записи?!

Я бы перефразировал:
"Вы видели живого человека, который смог успеть скопировать данные с умирающего SSD-носителя, при этом скопировать их неповреждёнными?"

[gosts 87]

А смысл ограничивать себя в скорости загрузки программ?

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

[Nicom]

Я бы перефразировал:
"Вы видели живого человека, который смог успеть скопировать данные с умирающего SSD-носителя?"

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

из-за чуть дольшей загрузки компьютера или чуть дольшего запуска программ.

Разница в скорости запуска приложений может доходить до 10 раз, например, при запуске виртуальных машин, браузеров, да того-же LibreOffice. Это иногда раздражает. Из этих секунд складывается наша жизнь.

[gosts 87]

Это иногда раздражает

Так у Вас какое железо? Какой процессор? Сколько ядер? Сколько Оперативки?

[Nicom]

Так у Вас какое железо? Какой процессор? Сколько ядер? Сколько Оперативки?

На работе у некоторых пользователей E6700/2/4GB. Здесь не корректное сравнение по этим параметрам. Намного более важный параметр - режим SATA интерфейса и его текущая скорость.