!
Linux User Group НовосибирскEdit: поправлено форматирование, BBCode после пересохранения всё похерил, поскольку не умеет во вложенность.
Так же добавлено уточнение, что стоит сделать scrub перед повторной балансировкой, если под метаданные нет места.
В продолжение поста
Опыт использования BTRFS.
Прошёл год, накопился опыт. В частности, полупромышленного использования в разработке с большими объёмами данных. Но обо всём по прорядку.
Встреченные проблемы
В общем и целом #
BTRFS не доставила за это время серьёзных проблем, а те, что были, проистекали из того, что ещё непривычно пользоваться.
- Из-за слишком усердной балансировки данных (
btrfs balance start -dusage=x /mount) система решила ужать область под метаданные впритык к их занятому объёму. Получилось так, что на диске свободно ещё несколько сотен GiB, но записать данные некуда, поскольку под метаданные места не зарезервировано.
Выглядит так, что Metadata забита:
# btrfs filesystem usage /mount
Overall:
Device size: 449.00GiB
Device allocated: 32.04GiB
Device unallocated: 416.96GiB
Device missing: 449.00GiB
Used: 28.82GiB
Free (estimated): 419.09GiB (min: 419.09GiB)
Data ratio: 1.00
Metadata ratio: 1.00
Global reserve: 74.44MiB (used: 0.00B)
Data,single: Size:30.01GiB, Used:27.88GiB (92.91%)
Metadata,single: Size:1.00GiB, Used:958.62MiB (98.16%) #<-- usage too big
System,single: Size:32.00MiB, Used:16.00KiB (0.05%)
Причина, вероятно, в том, что при высоком (от 60 и выше) -dusage балансировка забивает сегменты слишком плотно, а #BTRFS нужно пространство для CoW. Но честно скажу, так далеко не копал.
Решается запуском scrub и затем последовательным запуском балансировки данных для значений от 0 (очистка неиспользуемых блоков, не требует резервирования места) и 1, до 30-40 с шагом 5-10:
# btrfs scrub start -B /mount # ключ -B нужен, чтобы увидеть когда scrub закончится
# btrfs balance start -dusage=0 /mount
# btrfs balance start -dusage=1 /mount
# btrfs balance start -dusage=10 /mount
# btrfs balance start -dusage=20 /mount
# btrfs balance start -dusage=30 /mount
- Обратная ситуация, когда балансировка не делалась вобще и под данные ушло всё место. В такой ситуации не хватает места балансеру под перемещение блоков.
В логах и при действиях с файлами ругается #BTRFS no space left on device.
Использование диска выглядит примерно так, даже если занято всего 20GiB:
# btrfs filesystem show
Label: 'home' uuid: 4216df47-7fb8-442f-b432-5e732ab24166
Total devices 1 FS bytes used 147.94GiB
devid 1 size 298.02GiB used 298.02GiB path /
При этом удаление файлов не помогает, вполне возможно даже откажется работать, как и большая часть операций.
Поскольку файловая система CoW, удаление данных на ней требует места.
Решить это можно добавлением места, балансировкой и обратным сжатем места если необходимо. Если нет резерва по месту (как правило), можно добавить его за счёт подключения нового устройства, например флэшки. При этом устройство необходимо будет отформатировать в btrfs, но потом его можно будет убрать.
Делается это следующим образом:- Берём чистый диск, подключаем его.
- Добавляем его в #BTRFS (он будет отформатирован!):
# btrfs device add /dev/sdXX /btrfs_mount_point - После этого можно удалить лишние файлы, снапшоты, освободить место, если его действительно мало.
- Теперь можно сделать балансировку на новое устройство передав
-dusage=1:
btrfs balance start -dusage=1 /mount
Это заставит балансировщик перебросить данные на новый диск, но при этом освободит часть имеющихся чанков. Занимаемое место должно освободиться. - Следом можно сделать ещё несколько балансировок последовательно увеличивая значение в
-dusage до 30-40, чтобы оптимальнее распределить имеющиеся данные и освободить ещё места. - Когда места достаточно, чтобы освободить спасительное устройство и вы хотите его извлечь, необходимо удалить его из #BTRFS, при этом данные с него будут перенесены на оставшиеся диски:
btrfs device remove /dev/sdXX /btrfs_mount_point
если у вас старая версия btrfs-tools, вместо remove будет delete:
btrfs device delete /dev/sdXX /btrfs_mount_point - После окончания операции диск можно извлечь.
Не смотря на жуткий вид, обе проблемы решаются достаточно быстро и без потери данных. Можно ли их запустить так, что уже пробще будет снести и сделать заново я не уверен, в обоих случаях файловые системы заблокированы и отказываются что-либо записывать в себя.
Но лучше просто не допускать таких ситуаций делая балансировку с
-dusage=40 -musage=30 раз в месяц. Разница между Data Size и Used должна быть и это нормально, не надо пытаться забалансировать её так, что они сравняются, файловая система тогда будет неэффективно работать.
Разница между Metadata Size и Used быть обязана, иначе система встанет колом, поскольку это тот самый резерв места, куда метаданные будут записываться.
И стоит под #
BTRFS выбирать тихие диски, поскольку при балансировке они будут жужжать на полную.
Кое-что о прошлых выводах
- #BTRFS бесполезно ставить на HDD.
- На самом деле не всё так плохо. На HDD в BTRFS плохо себя чувствуют Базы Данных, особенно MySQL/MariaDB, даже при отключенном CoW. В остальном, пользоваться можно.
- #BTRFS на HDD по прежнему заметно медленнее EXT4, но не настолько, чтобы это вызывало серьёзный дискомфорт.
- #BTRFS RAID0 на 2 HDD в качестве хранилища не критичных к скорости данных (фильмы, музыка, репозитории, дампы БД, прочие бэкапы) показывает себя очень хорошо.
- #BTRFS на 8 SAS в mdraid RAID6 по скорости почти не уступает EXT4 развёрнутом прежде там же.
- Сжатие и дедупликация.
На деле оказались весьма серьёзным выигрышем. Для набора данных из исходных кодов, PNG и бинарных блобов в примерно равном соотношении сжатие lzo сокращает объём почти в 2 раза (с 16TiB до 8.5TiB).
Дедупликация на фоне этого не даёт такого впечатляющего выигрыша, но даже для наборов данных, где нет явных копий файлов, она по прежнему можно сократить объём занимаемого места на 6-10%.
В итоге из 16TiB занятого места на EXT4 мы получили ~8TiB на #BTRFS без заметной потери производительности.
