Использование файловой системы BTRFS
Форматирование разделов в Btrfs
mkfs.btrfs -n 32k -L arch ARCH_DEVICE
-n указываем размер узла дерева в котором хранятся данные. Чем он больше, тем лучше сжимается…
- Тут и далее вместо
ARCH_DEVICEуказываем/dev/nvme0n1p1.
Btrfs ‒ это одна из самых продвинутых файловых систем в Linux. Многие считают ZFS достойной альтернативой, но она не включена в ядро. Btrfs поддерживает механизм CoW (copy-on-write), создание снапшотов и сжатие данных… Снапшоты — это снимки файловой системы, точки для восстановления. Сжатие данных позволяет экономить место на диске, отказаться от использования архивов, но различные форматы изображений и видео и так поддерживают сжатие, поэтому оно не всегда полезно. За 4 года использования Btrfs я не сталкивался с какими-то критическими багами, и она меня не раз спасали от утраты данных. Простой пример: sudo rm -rf /<тут закрался пробел>.
В Btrfs нет привычных разделов, есть только подтома, которые можно сравнить с обычными каталогами. У них нет фиксированного размера, однако его можно ограничить с помощью quota. Снапшоты, если упускать некоторые детали, являются теми же самыми подтомами, те их можно монтировать и выполнять аналогичные операции.
Монтируем RootFS:
mount ARCH_DEVICE /mnt
Возможные сабвольюмы:
| subvolume | mount | описание |
|---|---|---|
@ |
/ |
Корневой каталог (системные файлы) |
@home |
/home |
Домашний каталог с пользовательскими данными. Нужен отдельный так как при откате системы к предыдущему состоянию очень важно сохранить существующий прогресс (куки браузера, конфиги, документы, файлы проектов и т.д.) |
@snapshots |
/.snapshots |
Содержит снапшоты корня, которые создает snapper |
@home.snapshots |
/home/.snapshots |
Содержит снапшоты хомяка, которые создает snapper |
@machines |
/var/lib/machines |
Если не существует, то создаст systemd |
@portables |
/var/lib/portables |
Если не существует, то создаст systemd |
@docker |
/var/lib/docker |
Рекомендации самого Docker с их сайта |
@docker_btrfs |
/var/lib/docker/btrfs |
Docker создает саьвольюмы по этому пути |
@var_lib |
/var/lib |
Вместо создания @machines, @portables, @docker можно создать только этот, если в /var/lib не будет храниться чего-то важного (предполагается, что будут делаться снапшоты только корня и/или хомяка) |
@var |
/var |
Аналогично выше описанному |
@var_log или просто @log |
/var/log |
Логи как правило не представляют интереса, но в снапшотах занимают дополнительное место |
@swap |
/swap или /var/swap, или /var/lib/swap |
Хранит файл подкачки. Должен монтироваться с nodatacow |
Подтома @machines, @portables, @.snapshots, @home.snapshots и @docker (опционально при использовании docker) нужны чтобы не заморачиваться с переносом вложенных подтомов при замене старого подтома на снапшот. Однако, вся эта плоская структура подтомов скорее нужна на серверах. Чтобы не заморачиваться я словетую использовать Btrfs Asssistant.
Создаем нужные подтома:
btrfs sub create /mnt/@
btrfs sub create /mnt/@home
# Рекомендуется
btrfs sub create /mnt/@cache
btrfs sub create /mnt/@log
Отмонтируем RootFS:
umount /mnt
Монтируем подтома и загрузочный раздел:
mount -o compress=zstd:6,subvol=@ ARCH_DEVICE /mnt
# Примонтируем остальное
# x-mount.mkdir создает несуществующую директорию
# mount -o x-mount.mkdir /dev/nvme0n1p2 /mnt/boot
# Используем более закрытые права на каталог с
mkdir -m 700 /mnt/boot
mount BOOT_DEVICE /mnt/boot
mount -o x-mount.mkdir,compress=zstd:6,subvol=@home ARCH_DEVICE /mnt/home
# Монтируем остальные подтома
mount -o x-mount.mkdir,compress=zstd:6,subvol=@cache ARCH_DEVICE /mnt/var/cache
mount -o x-mount.mkdir,compress=zstd:6,subvol=@log ARCH_DEVICE /mnt/var/log
Через двоеточие указывается уровень сжатия. На примере ниже оптимальный уровень сжатия 6. При нем скорость записи падает до 100 MiB/s, но при скачивании файлов из сети у нас скорость ~12 MiB/s (100 MBit/s)… Нам важна только скорость чтения, а она не падает меньше 2 GiB/s, те примерно равна скорость записи SSD (и не должна быть меньше нее в идеале). Протестировать уровни сжатия можно так:
$ zstd -T0 -b1 -e19
1#Synthetic 50% : 10000000 -> 3152996 (x3.172), 908.5 MB/s, 2367.7 MB/s
2#Synthetic 50% : 10000000 -> 3129011 (x3.196), 423.8 MB/s, 2312.6 MB/s
3#Synthetic 50% : 10000000 -> 3230491 (x3.096), 198.8 MB/s, 1852.2 MB/s
4#Synthetic 50% : 10000000 -> 3339961 (x2.994), 180.2 MB/s, 1591.4 MB/s
5#Synthetic 50% : 10000000 -> 3290137 (x3.039), 133.4 MB/s, 1586.0 MB/s
6#Synthetic 50% : 10000000 -> 3278503 (x3.050), 127.3 MB/s, 1615.1 MB/s
7#Synthetic 50% : 10000000 -> 3321448 (x3.011), 92.9 MB/s, 1484.6 MB/s
8#Synthetic 50% : 10000000 -> 3315141 (x3.016), 84.7 MB/s, 1477.1 MB/s
9#Synthetic 50% : 10000000 -> 3355994 (x2.980), 55.0 MB/s, 1322.0 MB/s
10#Synthetic 50% : 10000000 -> 3363166 (x2.973), 37.2 MB/s, 1190.3 MB/s
11#Synthetic 50% : 10000000 -> 3363170 (x2.973), 24.2 MB/s, 1150.9 MB/s
12#Synthetic 50% : 10000000 -> 3362882 (x2.974), 23.1 MB/s, 1147.6 MB/s
13#Synthetic 50% : 10000000 -> 3354692 (x2.981), 9.05 MB/s, 1195.2 MB/s
14#Synthetic 50% : 10000000 -> 3354678 (x2.981), 9.70 MB/s, 1167.4 MB/s
15#Synthetic 50% : 10000000 -> 3353801 (x2.982), 8.03 MB/s, 1157.6 MB/s
16#Synthetic 50% : 10000000 -> 3080678 (x3.246), 6.68 MB/s, 2248.9 MB/s
17#Synthetic 50% : 10000000 -> 3136878 (x3.188), 2.64 MB/s, 1908.5 MB/s
18#Synthetic 50% : 10000000 -> 3145664 (x3.179), 2.54 MB/s, 1823.0 MB/s
19#Synthetic 50% : 10000000 -> 3140424 (x3.184), 2.19 MB/s, 1843.2 MB/s
Форматирование внешнего usb диска в btrfs
sudo mkfs.btrfs -f -L Backup /dev/sdb
Для определения оптимальной силы сжатия запустить бенчмарк:
zstd -T0 -b1 -e19
Добавить запись в /etc/fstab:
UUID=<...> /mnt/backup btrfs noauto,user,compress=zstd:6 0 2
Создание снапшота:
sudo btrfs subvolume snapshot -r /mnt/backup /mnt/backup/.snapshots/test-snap
Удаление снапшота:
sudo btrfs subvolume delete /mnt/backup/.snapshots/test-snap
Просмотр информации об использовании btrfs:
btrfs filesystem usage /mnt/backup