Файловые системы со сжатием. Есть ли вообще выбор?

1. Не указывать крайнюю точку удаления файлов в logrotate, тогда старые логи будут сжиматься, но не удаляться.

2. Смонтировать образ qcow2 и хранить в нём.

3. Хранить логи в systemd-journald, там уже всё есть.

4. Хранить логи в специально придуманных для этого БД, типа clickhouse.

5. …

journald - https://habr.com/ru/articles/546368/

сжатие есть и в zfs. по слухам, как бы более устойчивая фс чем бутер.

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

fusecompress

Что мешает всю систему на BTRFS держать?

стандартного дебиана
btrfs

Исходя из того, что тебе logrotate якобы не подходит, у тебя отобрали zcat, zgrep и zless и забанили менеджер пакетов так что ты их установить не можешь? Ну тогда беда-горе-грусть

Ну вот я лично предпочитаю использовать Btrfs с LTS-ядром, так что Debian подходит хорошо. Там была проблема с сопровождением btrfs-progs, но сейчас решена.

А использовать агрегаторы логов типа loki с компрессией уже немондно?

Можно Ext4 разместить в ZVOL на ZFS и для него включить сжатие :)

Да и xfs поддерживает сжатие.

Есть ли другие варианты?

Накину ещё. bcachefs

Да и xfs поддерживает сжатие

Нет.

Да и xfs поддерживает сжатие.

Ты из какого года пишешь?

Попробуй решения на базе FUSE, но нужно проверить производительность, еще есть fuse-archive от google.

https://packages.debian.org/bookworm/fuse-zip

пля, да, чутка попутал. В RHEL можно сделать через VDO, но тоже выходит что через анус.

https://www.redhat.com/en/blog/disk-compression-RHEL8

да чет тупанул, оно конечно делается, но через VDO.

Сейчас в 2к25

‘К’ это тысяча, то есть 200025, а не 2025.

+100500 этому комментатору

папка с логом на BTRFS со сжатием

Я тут мимокрокодил... Недавно bcachefs в ядро добавили, в 6.7. Обещали плюшки btrfs+zfs в одном флаконе... Я пока не пользовался.

2р25коп это 20025коп

ок

у него javascript, наверно

если всех все устраивает зачем тебе «другое решение»?

оно разумеется есть и не одно, но ты тут же скажешь «зачем все усложнять когда мой бтрфс всех устраивает»

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

Пользоваться bcachefs пока явно рано, но выглядит скорее перспективно. Сможет ли она когда-нибудь вытеснить Btrfs — посмотрим, но здоровая конкуренция никому не повредит.

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

Должно вполне себе взлететь.

Разумеется отдельный диск, лучше отдельный хост с десятком ядер.

Потести на разных алгоритмах на файлах до 500Мб, тк сжатие отложенное, результат будет через несколько минут.

Я вангую что победит zstd 7+.

!) Не вздумай включать одновременно с шифрованием, как обычные дурачки-неосиляторы.

logrotate никак не мешает online доступу.

VDO это страшное недоразумение, где на тебя ложится мониторинг использования места в томе.

Wtf?

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

Также есть возможность использовать сжатие на уровне ниже ФС - LVM VDO. С этой опцией можно использовать Ext4.

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

Почитай, как оно работает. Если я правильно понял документацию, излишне оптимистичный выбор provisioned size может привести к ситуации, когда запись на ФС будет невозможна, потому что размер сжатых данных превышает размер LV. И это не ENOSPC, а EIO, потому что ошибку возвращает балочное устройство. Суть та же, что с Thin Pool, но там ты можешь просто не наглеть, и всё будет хорошо, а тут уже не прокатит.

А зачеи сжимать? Диск маловат или тут забабахать тему?

А зачеи сжимать?

Чтобы вывеска «плохая архитектура приложения» весила 500 Гб, а не 1.5 Тб. Меньше настроение портит.

папка с логом на BTRFS со сжатием на отдельном диске/разделе

Выглядит как приемлемый вариант. Только бэкапами озаботься (в прочем ими в любом случае надо озаботиться). Ну а вообще Aceler правильно сказал, переписывать надо на какую-то специализированную СУБД

В Линуксе до сих пор нет поддержки сжатия NTFS?

Итого:

logrotate мне правда не подходит. То что я назвал логами сервиса и что ими в общем является - это файловая база данных в самом плохом смысле этого слова. Взять и переписать? Спасибо за предложение.

Один большой системный интегратор уже переписывал то ПО что мы используем для одного крупного заказчика - получили терабайт в постгре…. в итоге, через пару лет я откатывал там всё на ванильное решение.

Я не программист, и в общем даже не сильный админ - устанавливаю сервис по мануалу, эксплуатирую десятилетиями. Да, кое что кое где устарело архитектурно, да есть проблемы роста определённые, красиво их решить - очень комплексно. БТРФС со сжатием вроде выглядит довольно просто.

Операторам гипервизора в общем пофиг, они не против такой активности на сторадже.

Будем пробовать бтрфс с определёнными ограничениями в выборе ОС.

Один большой системный интегратор уже переписывал то ПО что мы используем для одного крупного заказчика - получили терабайт в постгре…. в итоге, через пару лет я откатывал там всё на ванильное решение.

Я не программист, и в общем даже не сильный админ

ничего не трогайте, наймите специалиста

То что я назвал логами сервиса и что ими в общем является - это файловая база данных в самом плохом смысле этого слова

Будем пробовать бтрфс

Тогда стоит потестировать на разных алгоритмах сжатия сначала, начать с lzo и стандартного уровня zstd .

Пока пробую как раз lzo vs zstd (без параметров уровня сжатия) и не вижу разницы. На стенде две одинаковые VM показывают очень близкие результаты. Просто думал мало ли… вдруг есть какие-то «хорошие практики» для «плохих программ».

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

Остановился на zstd (уровень 3). Логи, характер которых довольно постоянен, жмутся аккурат в 10 раз. И при чтении и при записи один тред загружен на 100% и есть небольшая нагрузка на остальные треды, памяти система ест при этом не больше, чем с EXT4. Всё в общем работает как ожидается.

Нагрузку дал, всякие нештатности воспроизвёл - вроде бы всё хорошо. Совсем развалить ФС не удалось так, чтоб её прям чекать и восстанавливать пришлось (ДДшить рандом в производьные адреса - не спортивно).

Собственно, остался вопрос, можно ли заставить zstd сжатие использовать 2 треда и более, и… что бы еще проверить.

можно ли заставить zstd сжатие использовать 2 треда и более

Параметр thread_pool при монтировании. Хотя он по дефолту должен быть больше единицы.

Может быть на тестовой зоне просто было мало тредов. Попробую.

После некоторого времени эксплуатации в общем известного и хорошо изученного мной как админом сервиса в новой среде сформировались определённые выводы:

1. Переиначть софт может даже админ без разработчиков. Разработчикам никто пистолет к башке не приставлял и они сильно не разбирались с log4j, а админу пришлось. В итоге размер лога удалось сократить в два раза. И нет, дело не в изменении INFO на WARN.
2. От некоторых логов удалось отказаться настроив ротацию средствами log4j, т.к. оказалось что они хранят что-то странное, о нужности чего даже разработчик в течении недели не нашелся с внятным ответом. Жаль, что это было несколько процентов от объёма.
3. Примерно 50% логов изначальных никуда не деть. BTRFS с штатным zstd:3 жмёт это всё в 10 раз и это просто работает. Как-то так звезды встали что проца и памяти в достатке, а места нет. Вернее, базовые сервисники совершенно адекватно говорят, ну дадим мы тебе 4TB, а у тебя 500GB годовой прирост. Придумай что-нибудь.
4. Параллельно оказалось что SOLR, которого в зрелом корпоративном решении в избытке, оптимизирует свои индексы типа… копированием что ли. Это уже не логи. Т.е. было у него 100GB индексов, процедура оптимизации постепенно догоняет объём до 200GB а потом роняет до 95GB. Разработчик говорит «вы всё равно не поймёте», а индексы SOLR на чуть более соевом сжатии чем из коробки вообще не демонстрируют никакого падения производительности и позволяют сгладить изначальные скачки потребления места х2 во время процедур, которые не рекомендовались как регулярные, но теперь вполне могут исполняться регулярно.

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