У меня есть большое количество небольших файлов журналов, по существу только для записи, если мне не нужно смотреть на них по какой-либо причине. Прямо сейчас они накапливаются в подкаталогах для конкретного дня в папке журналов (например, 2018-12-29 вчера, 2018-12-30 на сегодня и т. д.), и я закончу tar/bzip2их позже в отдельные файлы в день.
Для меня это не очень удобно, и я подумал, что если бы я мог создавать сжатую файловую систему на каждый день, я мог бы писать напрямую в эти файловые системы, использовать меньше дискового пространства и не возвращаться и сжимать каждый каталог в архив . Это также упрощает проверку отдельных файлов позже, потому что я мог смонтировать файловую систему и использовать ее, однако - используйте grep, find, less и т. Д. Вместо того, чтобы пытаться использовать tar для потоковой передачи данных через некоторый командный конвейер.
Я знаю, что могу создать устройство с обратной связью произвольного размера, но я должен знать этот размер заранее, и если я угадаю «слишком высокий», я буду тратить дисковое пространство на неиспользуемое пространство, и если я выберу «слишком низкий», я закончится место на диске, и мое программное обеспечение выйдет из строя (или, по крайней мере, очень громко пожаловаться).
Я знаю, что могу создать разреженный файл, но я не совсем уверен, как это будет взаимодействовать с файловой системой, такой как extNfs или другие файловые системы, доступные в Linux; он может в конечном итоге расшириться намного больше, чем необходимо, из-за резервных суперблоков и тому подобного.
Есть ли способ создать петлевое устройство, которое может занимать минимальный объем физического пространства на диске?
Вы можете создать пул ZFS, сжатый gzip, на основе простых файлов и хранить в нем свои журналы. Не нужно было бы ничего делать, кроме записи журналов туда.
С самого начала они будут использовать только свой сжатый размер в файловых системах ZFS. После этого вы сможете читать данные (grep, find, less и т. Д.) И даже изменять, удалять их, даже если это не входит в ваши требования.
Если пул заполнится, вы можете либо увеличить внутренний файл (с включенным свойством autoexpand), либо добавить новые серверные файлы, и емкость файловой системы должна соответственно увеличиться.
Я знаю logrotate был предложен вам здесь, но если вы все же хотели бы продолжить идею сжатой файловой системы, почему бы вам не создать только эти после день закончился? Затем ваш сценарий оболочки вычислит размер папки журналирования, создаст файл устройства обратной связи необходимого размера, смонтирует образ обратной петли, переместит туда файлы журнала и, наконец, отключит образ обратной связи.
Я чувствую боль, если какое-то глупое приложение, с которым вы не можете / не можете делать что-либо, создает миллионы файлов журналов в день в каком-то каталоге, и вам все равно придется хранить их на диске в течение полугода или около того. В этом случае образ обратной петли может быть хорошей идеей, так как активное количество небольших файлов на каком-то разделе резко снизится.
Вы должны исследовать использование логротат (8) для помощи в управлении файлами журнала. Его можно настроить для переименования файлов в определенный формат даты и их автоматического сжатия. Вы также можете настроить его на ведение определенного количества журналов (и многих других вещей). После того, как вы настроите его так, как хотите, вы можете забыть об этом.
Также обратите внимание на инструменты, поставляемые с gzip / bzip2, например zgrep, zless, bzgrep, bzless и т.д. Они позволяют работать с архивами без создания каналов.