btrfs, quota, guaranteed free space case

Доброго времени суток.

Есть задача квотировать, т.е. ограничивать, не занимаемое место, а гарантировать свободное место (по возможности).

Опишу ситуацию подробнее:
есть раздел с логами, скажем 10 Гб (/var/log/application)
есть два application которые пишут логи (/var/log/application/app1 и /var/log/application/app2)

квоты предназначены для ограничения занимаемого места, т.е. я могу уже сейчас выставить лимиты для обоих subvolume по 5 гб (вариант #1), однако этот вариант мне не нравится, потому что приложения начинают срать в лог в относительно редких случаях, и могжет быть ситуация:
1. /var/log/application/app1 и /var/log/application/app2 содержат логов на 1 Гб
2. app2 начинает активно что-то писать в лог.

В варианте с классическим использованием квот (вариант #1) я получу /var/log/application/app2 забитый под завязку размером в 5 Гб, тогда как /var/log/application/app1 будет содержать 4 гб свободного места, которое не используется сейчас (и весьма вероятно не будет использоваться в ближайшее время).

Мне бы больше подошла ситуация с резервированием (по возможности) свободного места на /var/log/application/app1 и /var/log/application/app2, например каждому их них зарезервировано по 1 гб свободного места, тогда в этой же ситуации
app2 может рассчитывать на 10 Гб (лимит /var/log/application) - 1 Гб (занято на /var/log/application/app1) - 1 Гб (зарезервировано для /var/log/application/app1) = 8 Гб, что уже больше чем изначальных 5 Гб.

Учитывая что кол-во приложений >> 2 (на данный момент их десятки) вариант решения #2 позволит не иметь проблемы с отсутствием свободного места для логов при относительно небольшом размере диска, который выделен под систему логгирования в целом.

Вариант (#3) размещать все логи на одном разделе (без subvolume) чреват последствиями, когда нет свободного места, тогда теряются логи всех приложений до момента его очистки.

В общем проблему описал, хранить заведомо избыточный запас свободного дискового пространства под каждый app (вариант #1, но где лимит не 5, а 50 или 500 Гб) - считаю неоправданным и чрезвычайно затратным, потому и пришёл в варианту #2.

Вопрос можно ли его реализовать в рамках btrfs? Чтение man btrfs-qgroup не дало ответа умеет ли она то, что я от неё хочу. Может быть аналоги умеют что-то подобное, например zfs, но беглый взгляд на возможности её квот, навёл на мысль что идеология там такая же?

Спасибо за ответы.

На БТРе вообще никогда не

На БТРе вообще никогда не знаешь точно, сколько места осталось :), можно только приблизительно оценить.

И у меня для тебя плохие новости: системными средствами решения для тебя нет - надо изобретать свой велосипед (скрипт), который будет периодически проверять, удалять ненужное/устаревшее и/или убивать активных писателей... ;) Можешь сделать это как дополнение к твоему решению с квотами, хотя смысла особого в этом нет.

Но есть хорошая новость: может твою жизнь упростит logrotate. Можешь его настроить на максимально допустимый размер лога и периодически его вызывать. Задашь нужное число архивированных логов (рекомендую их не сжимать для скорости) и будет тебе счастье! :) И он также умеет бороться с (постоянно) открытыми файлами логов.

SysA написал(а): И у меня для

SysA написал(а):
И у меня для тебя плохие новости: системными средствами решения для тебя нет

этого я и боялся, хотя и ожидал что так будет.

SysA написал(а):
надо изобретать свой велосипед (скрипт)

вариант, однако хотел поискать перед этим есть ли системное решение задачи.

SysA написал(а):
Но есть хорошая новость: может твою жизнь упростит logrotate

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

SysA, cпасибо за ответ!

Дисков добавь! :)сегодня

Дисков добавь! :)

сегодня диски копейки стоят... У меня некоторые подсистемы за день 10 Гиг (каждая!) генерят... :)

Поэтому на серверах логирования (локальных логов нет, - "не царское это дело" (С) + безопасность, да и И/О жрет!) стоит по полторы теры на логи чуть меньше тысячи подсистем. Вот в среднем получается по полтора гига на систему - вроде бы и немного! Даже меньше, чем ты планируешь...

включи сжатие - основную

включи сжатие - основную проблему это не решит, но текстовых логов станет влезать гораздо больше )

Настройки просмотра комментариев

Выберите нужный метод показа комментариев и нажмите "Сохранить установки".