← All posts tagged btrfs

Self-Perfection

Надоело мне, что логи journald занимают у меня под гигабайт, а хранят при этом информации за 2 недели. journald туп и не поддерживает сжатие логов. Так что идея была перенести `/var/log` на btrfs со сжатием. Делюсь опытом.

С одной стороны, работает довольно изкоробочно: просто смонтировать btrfs с compress=[lzo|btrfs] достаточно. Хотя journald по-умолчанию помечает `/var/log` как nocow, который не сжимается, но `btrfs filesystem defrag -c` всё же сжимает nocow файлы, и journald проводит дефрагментацию старых (сротированных) логов на btrfs. Ну для надёжности можно ещё сделать `chattr -R +c /var/log/journal`. В целом у меня работает решение, влезает теперь месяц логов на гигабайтный `/var/log`.

Нюанс 1: стоит ограничить размер одного файла логов, чтобы ротация происходила чаще. Я пока живу с `SystemMaxFileSize=16M`.

Нюанс 2: btrfs стоит создавать с ключом `--mixed`, если он будет у вас меньше нескольких гигабайт. И монтировать с опцией `autodefrag` — обновление логов journald ведёт к большой их фрагментации, я видел десятки тысяч фрагментов до включения autodefrag.

Нюанс 3: как посмотреть, работает ли сжатие? Изкоробочных инструментов нет, в интернетах можно нарыть питоновский скрипт btrfs-debugfs. Играясь с ним выяснил, что btrfs сжимает файл блокам по 128 KiB, каждый блок на диске занимает места кратно размеру сектора, так что меньше 4KiB не может занять. Поэтому сжатие получается не такое сильное как при сжатии напрямую lzop или gzip -3.

Ещё на первый взгляд у меня почему-то сжимаются только system файлы, но не user. Пока предполагаю из-за того что пользовательских логов мало, а ротируется system и user лог параллельно, так что system ротируется после двух аллокаций по 8 MiB, а пользовательский — как есть, 8 MiB. Надо бы добраться до исходников journald, посмотреть какая у него внутри логика.

Self-Perfection

С недавних пор у меня весь rootfs на SSD. И вот смотрел я смотрел, на график записи на SSD, не вытерпел и решил как-то пооптимизировать/сократить их количество.

Итак в начале был Btrfs c relatime,compress=lzo,ssd,space_cache
MariaDB, постоянно дёргаемая Tiny Tiny RSS, давала в среднем где-то 80 KiB/sec записи на диск (а это почти 7 GiB/день!).
Пересоздал /var/lib/mysql c chattr +C (отключение copy on write). Запись от MariaDB снизилась до 70 KiB/sec

Попробовал для эксперимента перетащить /var/lib/mysql на ext4 раздел.... 30 KiB/sec!!!
Даже если примонтировать с data=journal (который, походу, пользы не приноситв этом случае, т.к. и так по-умолчанию включен innodb_doublewrite), получается всего 60 KiB/sec, что меньше, чем на Btrfs.

Смотрю на свои эксперименты и думаю, что /var надо нафиг с Btrfs выносить целиком.

Self-Perfection

fsync на btrfs ужасно тормозной, как следствие, dpkg на btrfs работает очень медленно. Так что апгрейдить xubuntu до 12.10 не запустив обновлятор через eatmydata было бооооольшой ошибкой. Все пакеты скачались к 13:20, и оно до сих пор обновляется. Смотрите на таймстампы
$ tailf /var/log/dpkg.log|grep upgrade
2012-10-21 18:52:37 upgrade iptables:amd64 1.4.12-1ubuntu4 1.4.12-2ubuntu2
2012-10-21 18:52:54 upgrade iputils-tracepath:amd64 3:20101006-1ubuntu1 3:20101006-3ubuntu1
2012-10-21 18:53:22 upgrade irqbalance:amd64 0.56-1ubuntu4 1.0.3-1ubuntu2
2012-10-21 18:53:38 upgrade krb5-locales:all 1.10+dfsg~beta1-2ubuntu0.3 1.10.1+dfsg-2
2012-10-21 18:53:49 upgrade lshw:amd64 02.15-2 02.16-1
2012-10-21 18:54:05 upgrade lsof:amd64 4.81.dfsg.1-1build1 4.86+dfsg-1ubuntu1
2012-10-21 18:54:21 upgrade ltrace:amd64 0.5.3-2.1ubuntu2 0.5.3-2.1ubuntu3
а обновить нужно over 1k пакетов...