LINUX.ORG.RU

Делаем машину времени с Btrfs

 , ,

Делаем машину времени с Btrfs

2

3

Btrfs – это файловая система с легковесными снапшотами, которая позволяет создать самую настоящую машину времени, делая снимки состояния файловой системы (снапшоты) и монтировать их на лету. Этой файловой системе скоро стукнет 16, а значит уже можно ее попробовать.

ПРЕДУПРЕЖДЕНИЕ: лучше не использовать Btrfs на HDD особенно с SMR. Из-за низкой скорости произвольного доступа на устаревших типах носителей Btrfs может очень сильно разочаровать (как и ZFS).

Btrfs – файловая система, по возможностям сравнимая с ZFS, но в отличии от последней включена в ядро Linux, что несомненно является преимуществом. Потенциальный же убийца Btrfs – Cachefs – пока в зачаточной стадии разработки и с новыми версиями лишь показывает регресс производительности, что останавливает автора сиих строк от знакомства с последней. Btrfs используют такие компании как Facebook и Google, так что с доводами про миллиард мух – сразу мимо.

Btrfs является файловой системой по умолчанию в дистрибутивах Fedora, OpenSUSE, Garuda Linux и тд. Сия статья не будет обзорной на возможности ФС, я расскажу лишь как правильно ее готовить. И начнем мы с переезда на нее.

Btrfs требует наличия пакета btrfs-progs. В арче и, упаси господи, убунте он называется одинаково. Ставим.

Для начала нам нужно создать новый раздел с Btrfs. Для этого можно воспользоваться Gparted. Для ручного разбиения исп. cfdisk и info mkfs.btrfs.

В Btrfs существуют подтома (subvolumes). Изначально на разделе один корневой подтом с id=5. Если при монтировании в опциях не указать подтом, то будет примонтирован корневой. На нем мы можем создать неограниченное число вложенных в друг друга подтомов. Подтома можно монтировать в отдельные точки монтирования, при этом применяя к ним различные методы сжатия и т.п. Снапшоты – это такие же подтома, за исключением некоторых деталей…

Для наших целей нужно три подтома:

ПодтомТочка монтирования
@/
@home/home
@var_log/var/log

Далее мы монтируем корневую файловую систему:

mount /dev/sda3 /mnt

И создаем подтома:

cd /mnt
btrfs su cr @
btrfs su cr @home
btrfs su cr @var_log

Для чего нужно именно три подтома, я объясню позже. Сейчас смонтируем их и перенесем на них файлы:

mount -o noatime,compress=zstd:3,subvol=@ /dev/sda3 /mnt
mount -o x-mount.mkdir,noatime,compress=zstd:3,subvol=@home /dev/sda3 /mnt/home
mount -o x-mount.mkdir,noatime,compress=zstd:3,subvol=@var_log /dev/sda3 /mnt/var/log

rsync -avh \
   --exclude "/boot/*" \
   --exclude "/efi/*" \
   --exclude "/media/*" \
   --exclude "/dev/*" \
   --exclude "/proc/*" \
   --exclude "/sys/*" \
   --exclude "/tmp/*" \
   --exclude "/run/*" \
   --exclude "/mnt/*" \
   --exclude "/lost+found/*" \
   / /mnt

Не забудьте отредактировать /mnt/etc/fstab:

# нужно указать точки монтирования для @, @home, @var_log
UUID=<UUID>  /           btrfs  rw,noatime,compress=zstd:3,commit=120,subvol=@
...

ID раздела с Btrfs можно подсмотреть в том же Gparted.


Небольшое лирическое отступление.

Btrfs желательно монтировать с noatime (не сохранять время доступа к файлу) для минимизации операций записи для этих же целей увеличено время коммита изменений файловой системы (переодичности записи данных на диск, по умолчанию она - 30 секунд). Можно так же попробовать lazytime — время доступа к файлу хранится в RAM и сохраняется при выключении (?).

Касательно, сжатия данных – лучшим методом сжатия на домашней пекарне является zstd. Его преимущество в сравнении с другими алгоритмами заключается в высокой скорости распаковки, что на живой системе важнее уровня сжатия. На слабых компьютерах используется zstd:1 или даже lzo:1, а вот на более мощных – уровни от 3 до 9. Для проверки скорости zstd на различных уровнях сжатия:

zstd -T0 -b3 -e15

Сами решайте какой уровень вам подходит. Комфортно можно жить со скоростью записи вплоть до 12 MiB/s (это максимальная скорость скачки файлов в мегабайтах при канале 100 MBit/s). Те на каком-нибудь бекап-сервере можно и zstd:9 использовать. В Btrfs 15-ый уровень ранее и вероятно сейчас является максимальным, хотя сама zstd поддерживает уровни вплоть до 29-го (?).


Для того чтобы система грузилась, chroot-имся в /mnt и переустанавливаем grub (или редактируем конфиги – кому как нравится), либо переписываем конфиг для systemd-boot.

Конфиг для systemd-boot будет выглядеть так:

[skipped]
options root=UUID=<UUID> rootflags=subvol=@ rw quiet

Тут из непривычного – тут нужно передать subvol через rootflags.

После сделанного перегружаемся…

Для автоматического снятия снапшотов применяется утилита snapper, о которой я узнал от гентушников. Так вот три подтома нам нужны чтобы снимать снапшоты с них с разной периодичностью. Какую-то ценность представляют данные в хомяке, поэтому снапшоты хомяка будут делаться чаще всего; снапшоты корня будут делаться при старте системы и обновлении, а вот логи – это часто мусор, утрата которого не имеет значения.

Snapper, конечно, хорош, но он не дает такого положительного опыта, как тыкание мышкой по интерфейсу. В качестве GUI для Snapper я использую Btrfs Assistant. О нем я узнал в чате пользователей Garuda Linux. О нем я выше упоминал. Пользователи дистрибутивов на основе Arch Linux могут установить все, используя yay/paru:

yay -S snapper btrfs-assistant btrfsmaintenance

Запускаем Btrfs Assistant, заходим в Snapper Settings.

Screenshot_20240523_154553

Snapper каждый час делает снапшоты. Через его конфиг мы можем указать сколько оставлять последних ежечасных снапшотов, первых за сутки, неделю, месяц и год…

  • Для @ ставим 2 дневных, остальные в 0. Общее количество снапшотов не трогаем (вместо 50 можно даже больше поставить).
  • Для @home - 5 часовых, 10 дневных, остальное по 0.
  • Обязательно отмечаем: Snapper timeline enabled, Snapper cleanup enabled, Snapper boot enabled.

Для того чтобы делались снапшоты при обновлении системы, ставим хук для pacman:

yay -S snap-pac

Теперь поговорим про восстановление системы. Тут все просто. В случае удаления чего-то важного, неудачного обновления, можно перейти во вкладку Snapper, далее ниже Browse/Restore и сделать восстановления из снапшота. При этой операции будет сделан снапшот текущего подтома, подлежащего восстановлению, а потом он будет заменен на выбранный снимок/снапшот. Так же можно восстановить отдельные файлы.

Screenshot_20240523_154755

Так же обратите внимание на вкладку Btrfs maintance. Там вас могут заинтересовать такие операции как scrub и balance. Первая проверяет контрольные суммы блоков и исправляет ошибки, вызванные, например, неожиданным отключением электричества (такое происходит редко, частые ошибки чексум свидетельствую о скорой смерти SSD); вторая – позволяет вернуть место занятое заголовками.

Ручной вызов команд:

sudo btrfs scrub start -Bd /

sudo btrfs balance start -dusage=10 -musage=10 /

Чтобы посмотреть сколько места занимает файловая система:

sudo btrfs fi us /

Команда btrfs позволяет вместо filesystem писать fi и f, те сокращать слова вплоть до одной буквы. Выше уже был пример с su вместо subvolume и crcreate.

Данная команда всегда показывает место, занятое корневым подтомом, поэтому не обязательно указывать полный путь.



Проверено: hobbit ()
Последнее исправление: rtxtxtrx (всего исправлений: 13)

По сравнению с openSUSE — полная хрень. При любых операциях с настройкой ОС через yast2 или zypper снапшот Btrfs создается автоматически и добавляется в пропатченный GRUB2. Так что если накосячил и порушил ОС, достаточно перезагрузиться в состояние до и удалить снапшот из GUI.

zsys в Ubuntu на ZFS обеспечивает тот же функционал (правда без GUI), как и интеграция ZFS в Solaris 11.

А у тебя для восстановления ОС должна быть минимально работоспособна, а желательно и с GUI. Особенно это на Arch смешно, который, как я напомню, хранит по умолчанию только 1 версию ядра.

Ну и на счет снапшотов каждый час — просто отформатируй /home в NILFS2 — у тебя любые измения файлов будет создавать снапшоты, которые будут храниться, пока есть возможность и место не кончится.

GUI утилит нет, зато фичи очень классные, и ФС вполне заслуженная и старая, просто малоизвестная: https://habr.com/ru/companies/ruvds/articles/477388/

Vsevolod-linuxoid ★★★★★
()
Последнее исправление: Vsevolod-linuxoid (всего исправлений: 4)

снапшоты

снапшоты

снапшоты

снапшоты

снапшоты

и это все? а для чего это нужно? нарукожопил, все упало, восстановился из снапшота? мне такое не нужно… есть какие нибудь другие плюсы? например работает в 2 раза быстрее того же ext4 и быть может ресурс винта лучше бережет.

amd_amd ★★★★★
()
Ответ на: комментарий от amd_amd

гугли " фс которая быстрее etx4" и будет тебе щастие. а тут другое… :)
бутер он про возможности и функции, расплачиваться приходиться скоростью…

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

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

в бутере есть отличная система btrfs send/receive позволяющая снапшоты сливать в файл и оттуда же восстанавливать. причем с возможностью инкрементальных обновлений.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 2)

Неплохо бы исключать из снепшотов ~/.cache, а то быстро заезживается. Я еще ~/Downloads убираю.

akho
()
Ответ на: комментарий от amd_amd

В повседневной жизни можно не задумываясь делать Ctrl+C Ctrl+V хоть на 100-гиговой папке, и сделать это 100 раз, занимать это все будет те же 100 ГБ.

Прозрачная компрессия - для флатпаков самое то, ну или для крошечных ссд и медленнющих хардов.

Для дистрохоперов не нужно делать раздел под /home, достаточно сабволюма, и никаких LVM. Да и можно ставить дистры в тот же раздел, просто в разные сабволюмы.

fumanchez
()
Ответ на: комментарий от Vsevolod-linuxoid

При любых операциях с настройкой ОС через yast2 или zypper снапшот Btrfs создается автоматически и добавляется в пропатченный GRUB2.

В арче нет ничего по дефолту, никакая файловая система для него не является дефолтной, а поэтому такой преднастройки под btrfs нет, по мне достаточно хука для пакмана, который делает снапшоты. Но я уверен, что и в раче такое есть

zsys

sanoid (есть в AUR)

интеграция ZFS в Solaris 11

даже не линакс как и линакс не юникс

А у тебя для восстановления ОС должна быть минимально работоспособна… GUI

Btrfs Assistant - это просто гуй к snapper, а snapper - cli, так что не нужна GUI

Особенно это на Arch смешно, который, как я напомню, хранит по умолчанию только 1 версию ядра

В репозиториях арча хранятся все старые версии пакетов в тч ядра, есть утилиты типа downgrade для этого, а можно и «вручную». Не знаю что ты тут имел в виду, но если использовать гроб, то он может грузить ядро из Btrfs раздела, а значит ты можешь и ядро в снапшоты засунуть, многие даже и не догадываются об этом…

Ну и на счет снапшотов каждый час — просто отформатируй /home в NILFS2

Они вообще файлы не удаляет, а не снапшоты делает. Это принципиально другая файловая система. Админам локалхоста нужна лишь возможность восстановить случайно удаленные фоточки мертвых родственников…

rtxtxtrx
() автор топика
Последнее исправление: rtxtxtrx (всего исправлений: 2)
Ответ на: комментарий от dataman

Древовидные, CoW, прогрессивные, не такие как все… Про семейство все верно было

rtxtxtrx
() автор топика
Ответ на: комментарий от amd_amd

быть может ресурс винта лучше бережет

Вот я только сейчас выкачал лог с ошибками говнобиржи на похапе:

❯ du -h error_log                               
7.2G    error_log
                                                                                                    
❯ sudo compsize error_log                       
Processed 1 file, 58424 regular extents (58424 refs), 0 inline.
Type       Perc     Disk Usage   Uncompressed Referenced  
TOTAL        3%      228M         7.1G         7.1G       
zstd         3%      228M         7.1G         7.1G 

Я выкачал 7 гигов говна, а на диск было записано только 228 мегабайт данных, те в 33 раза меньше чем записалось бы на ext4, потому как там уникальных ошибок мало и более 99% сообщений об ошибке повторяются.

например работает в 2 раза быстрее того же ext4

Среднестатистический SSD файл размером 7 гигов будет читать 5 секунд, с Btrfs он же будет прочитан и распакован за доли секунды, получится что скорость в 10-20 раз быстрее. Но к сожалению этот пример из разряда идеальных. В реальности скорость записи будет ниже, скорость чтения - ненамного выше или такая же, экономия места ~25-30%, которые, правда, сожрут снапшоты, но к ним нужно относиться как к отложенному удалению файлов. Btrfs не хватает онлайн-дедупликации. У меня 150 гигов исходников хранится, и ес-но куча одинаковых файлов того же wordpress, а так же ужас на node.js, где в каждом node_modules 95% файлов повторятеся, то есть с ней выигрыш был бы колоссальным. В ZFS она есть, и ес-но она тормозит, быстрой ее не сделать, да еще раму нежрущей, и обычному юзверю она не нужна (думаю понятно почему), на сервере ею тоже жертвуют в угоду скорости…

rtxtxtrx
() автор топика

Очень правильная картинка. Когда этот аппарат наезжает на мину - все файлы внутри становятся мёртвенькими

serg002 ★★★
()
Ответ на: комментарий от NyXzOr

чтото типа да, надо поизучать. спасибо !!
надо обратно бутер на виртуалку намазать - покывирять чутка современность.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от token_polyak

sanoid разрабатывается zfs-сообществом и для zfs, то шЮтка, такая «смешная» как моя про ладу

rtxtxtrx
() автор топика
Ответ на: комментарий от rtxtxtrx

вероятность потерять весь файл в случае ошибки в одной ячейке, а не один конкретный байт в этой ячейке, взлетает в 33 раза минимум :)
будь взрослым мальчик, у любой медали есть обратная сторона…. :)

сел бы лучше и нарисовал онлайн-дедупликатор для бутера.

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от pfg

он есть

Space-efficient hash table and matching algorithms - can use as little as 1 GB hash table per 10 TB unique data (0.1GB/TB)

И даже меньше жрет чем в ZFS


но скорее не нужен

rtxtxtrx
() автор топика
Последнее исправление: rtxtxtrx (всего исправлений: 2)
Ответ на: комментарий от pfg

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

rtxtxtrx
() автор топика
Ответ на: комментарий от rtxtxtrx

создаtim блочное устройство в ram. форматируешь в бутер.
скриптом заполняешь и наводишь беспорядок. потом дефрагментируешь и ищешь потери.
в конце пишешь красивую статью. мне тож будет интересно.

pfg ★★★★★
()
Ответ на: комментарий от pfg

скриптом заполняешь и наводишь беспорядок. потом дефрагментируешь и ищешь потери.

Но зачем?


Attention! Bees uses kernel internal structures and looks in /usr/src/linux. Everytime, you upgrade the kernel, you MUST recompile bees. If you have installed pirx, this goes automagically. But not now. You must it do by hand.

emerge sys-fs/bees
cat<<EOT > /etc/bees/root.conf
UUID=$(blkid -s UUID -o value /dev/nvme0n1p2)
OPTIONS="--strip-paths --no-timestamps --thread-count 1 --verbose 0"
DB_SIZE=$((256*1024*1024*4))
EOT
systemctl enable beesd@$(blkid -s UUID -o value /dev/nvme0n1p2)
systemctl start beesd@$(blkid -s UUID -o value /dev/nvme0n1p2)
systemctl status beesd@$(blkid -s UUID -o value /dev/nvme0n1p2)

Для RAID тут по идее нужно UUID первого раздела указать… Но я проверять не буду… надо подумать

rtxtxtrx
() автор топика
Ответ на: комментарий от pfg

То стороняя утилита, разработанная неизвестно кем, точнее известно, но он к самому Btrfs отношения не имеет

rtxtxtrx
() автор топика
Ответ на: комментарий от pfg

таки много есть фс что лучше и быстрее Ext4, JFSutils/XFS можно подмаунтить в любой микроволновке, только я с недавних пор стала не любить F2FS, один раз выдернула комп из розетки, минус фс, ну и срёт раму, там так-то на историю создания от производителя картофельный девайсов, да экранов для телявизоров в прирципе насрать

FSBinyourx86
()
Ответ на: комментарий от dataman

Ну да, сравнил хрен с пальцем. Инженеры (и менеджеры) Oracle так и не смогли признаться ни себе, ни людям, что то, что годится для СУБД, не годится для ФС.

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от FSBinyourx86

The data contained on F2FS partitions can become unusable if the kernel version on the running machine is older than the kernel version used to create the partition

Надежность(c)

rtxtxtrx
() автор топика
Ответ на: комментарий от FSBinyourx86

главное отличие f2fs что он при записи, файл кеширует в память и отвечает что файл записан. хотя он не записан. зато скорость пользователю показывает гигансткую.

pfg ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.