Portál AbcLinuxu, 15. května 2025 08:33
Zdravím,
mám pár otázek ohledně Btrfs, na které se mi nedaří najít odpověď. Před časem jsem si zkusil nainstalovat OpenSUSE a instalátor mi vytvořil ~ 8 subvolumes. Včera jsem si zkusil nainstalovat Mint 20 a v instalátoru jsem vytvořil jeden oddíl 50 GB, přípojný bod / a souborový systém btrfs. Po instalaci bylo vidět, že instalátor vytvořil pouze 2 subvolumes - @/ a @home. Chci se zeptat:
Řešení dotazu:
Dočasná postradatelná data jsou v /tmp, /var/cache a dalších.
To dalších znamená přesně co?
Vytvoření subvolume znamená překopírování dat a úpravu /etc/fstab.
Pokud vím, tak na stejné úrovni nelze vytvořit subvolume se stejným názvem, jaký už daná úroveň obsahuje. Takže bych musel např. @var vytvořit např. v /home, nastavit stejná práva jako má /var, pak překopírovat soubory, smazat /var, vložit /home/@var do / a pak upravit /etc/fstab, Samozřejmě bych vyčlenil @var/lib a @var/cache jako další subvolumes. OK?
A ještě jsem se zapomněl zeptat, jestli to celé lze pořešit při instalaci? Na netu jsem nic nenašel.
/home/tomas/projekty/projekt1, projekt2
(projekt1 je pochopitelně nějaký lidský název) budou subvolumes. Osobně používám btrfs sub create
skoro denně.
Potom můžete snadno dělat jejich snapshoty, já jsem si zvykl je dávat do složky ~/projekty/.snap
, ale můžete je vytvářet kdekoliv. (btrfs sub snap projekt1 ./snap/2020-08-09-projekt1
)
Potom je celkem dobré jednotlivé uživatelské homes mít jako subvolumy Tedy ne celý /home
, ale /home/tomas
, /home/petr
apod.
Co se týče systémových adresářů, asi bych to jednak neřešil, ale pokud chcete, můžete si to přesunout po instalaci (tj nabootovat nějaké livecd a z toho si uspořádat disk).
Díky za vysvětlení.
Nechápu, odkud se vzal ten zvyk pojmenovávat subvolumes pomocí @.
No, takhle mi to pojmenoval instalátor SUSE i Mintu sám.
Co se týče systémových adresářů, asi bych to jednak neřešil, ale pokud chcete, můžete si to přesunout po instalaci (tj nabootovat nějaké livecd a z toho si uspořádat disk).
Jak? Prosím o názorný příklad. Dejme tomu, že chci udělat subvolume z /var. Nabootuji LiveCD a co dál?
Jak? Prosím o názorný příklad. Dejme tomu, že chci udělat subvolume z /var. Nabootuji LiveCD a co dál?Tak je potřeba někam namountovat ten systémový FS, takže dejme tomu do
/mnt/rootfs
(některé livecd se to snaží někam připojit samy, to lze zjistit třeba v lsblk
). Potom stačí:
cd /mnt/rootfs mv var var.old btrfs sub create var rsync -a var.old/ var/a je to. Nabootovat zpět OS z disku, zkontrolovat, zda je vše ok a časem
/var.old
smazat.
Moc ti DĚKUJI!
Na tvých stránkách jsem si o btrfs četl už dávno. Za poslední 3 dny jsem čtením o tomto fs strávil ~ 15 hodin, ale na to, na co jsem se ptal jsem nikde nenarazil. Zatím si jen tak hraji. Dal jsem si Mint 20+btrfs na volný hdd a snažím se v tom zorientovat. Až se tak stane, hodlám na btrfs přejít - čistá instalace. Dost si mi právě pomohl, abych mohl dál sám zkoušet a experimentovat.
Ještě jednou díky.
Nechápu, odkud se vzal ten zvyk pojmenovávat subvolumes pomocí @.No, takhle mi to pojmenoval instalátor SUSE i Mintu sám.
OpenSUSE okolo má okolo btrfs subvolumes a snapshotů propracovanou podporu, kdy třeba při update systému automaticky dělá konzistentní snapshot starého a pak z grubu umožňuje nabootovat do těchto starších.
Ta označení se @ se možná berou odtud, aby ty skripty poznaly, co jsou uživatelský a co systémový subvolumes a podle toho to něco dělalo.
Nevím jak je to v Mintu, ale pokud tam už jsou také nějaká klikátka, tak pozor na ruční zásahy do subvolumes, aby to tyhle věci nerozbilo.
Které adresáře z / je dobré mít jako subvolume a proč?
systemd-homed
a libvirtd
; oba vědí, co dělají a proč.Já mívám jako subvolume většinou:
/
, aby se dal filesystém sdílet mezi několika distribucemi. V bootloaderu je pak potřeba mít například rootflags=subvol=archlinux_root
, pokud se subvolume jmenuje archlinux_root
./var
, protože proč ne, hodně se tam toho mění, atomické snapshoty taky dávají smysl a jednou v budoucnu, až bude možné nastavit jinou redundanci nebo jiné šifrování pro každou subvolume, oddělený /var
se může hodit./home
, pokud člověk nepoužívá systemd-homed
a chce mít všechny domovské adresáře nějak společně snapshotované a zálohované. Tohle je ale celkem sporné a asi bych to dnes už nedoporučoval; ať tohle prostě spravuje systemd-homed
pro každého uživatele zvlášť. (Pořád se to může hodit, pokud jsou v /home
napevno nějací (napůl) fiktivní uživatelé, kteří se nepřihlašují.)/etc
, ale tady bacha; zatímco například subvolume pro /var
může být klidně v kořenovém adresáři (třeba pod názvem archlinux_var
(nebo podle libosti, pro každou distribuci sdílející filesystém) a mountovat se pak dá do /var
(s patřičným optionem subvol=archlinux_var
)), u /etc
tohle takhle nejde; subvolume /etc
je dobré vytvořit rovnou jako /etc
(nebo tedy archlinux_root/etc
), aby byl mount vždy automatický. Jinak to většinou nebude fungovat; bude tam spousta hádek s GRUBem, s vytvářením initramdisků atd. Navíc se beztak /etc
váže (a má vázat) ke kořenovému adresáři, takže je celkem OK, když se nemountuje úplně odděleně./boot
, protože v dnešní době je /boot
samozřejmě adresář (nebo subvolume), nikoliv oddíl. Je trochu dilemma, jestli to má být obyčejný adresář a má existovat pro každé distro zvlášť (což má výhodu v tom, že každé distro si může spravovat vlastní konfiguraci GRUBu) nebo jestli má existovat možnost sdílení mezi distry. Já volím kompromis: /boot
a priori nesdílím, ale tu možnost nechávám otevřenou. Proto subvolume. Bude se jmenovat třeba archlinux_boot
a do /boot
se namountuje třeba s volbami noauto,x-systemd.automount,subvol=archlinux_boot
. Pozor, GRUB pak samozřejmě potřebuje mít správně cesty od kořenového adresáře (implicitní subvolume), takže tam bude mít něco jako: initrd /archlinux_boot/(intel|amd)-ucode.img initrd /archlinux_boot/initramfs-linux.img linux /archlinux_boot/vmlinuz-linux root=UUID=... ro rootflags=subvol=archlinux_root ...Tohle^^^ ovšem už asi tak 5+ let umí automaticky zajistit
update-grub
, takže by to mělo být v pohodě, jen tak samo od sebe.Musím je vytvořit při instalaci?
Ne. Ale pak je to celkem voser, když je chceš vytvořit dodatečně a jedná se o nějaký systémový adresář, třeba /
nebo /var
:
/etc/fstab
a initramdiskNe že by to^^^ byl nepřekonatelný problém, to jistě ne; už asi desetkrát mě to potkalo. Ale … právě proto raději vyřeším subvolume už při instalaci.
Pokud ano jak?
btrfs subvolume create ...
Můžu po instalaci, kdy instalátor vytvořil jako subvolumes pouze @/ a @home udělat např. z /var @var?
Ano.
(Předně je dobré si všimnout, že zavináč nemá žádný speciální význam; je to prostě jenom součást názvu subvolume (a subvolume se v Btrfs (na rozdíl od ZFS) (skoro) vždy objevuje jako implicitně namountovaný adresář někde ve filesystému (a nežije v odděleném stromě filesystémů jako u ZFS).)
Jak?
Postup záleží na tom, co je původně /var
.
/var
subvolume:# při bootu z recovery média; ne přímo na systému! mv /var /@var mkdir /var chmod --reference=/@var /var chown --reference=/@var /var
/var
obyčejný adresář:# při bootu z recovery média; ne přímo na systému! btrfs subvolume create /@var chmod --reference=/var /@var chown --reference=/var /@var cd /var mv * .[^.]* ..?* /@var
/etc/fstab
, aby tam bylo něco rozumného.
UUID=... /var btrfs defaults,noatime,nodiratime,subvol=@var 0 0
Nicméně já osobně bych asi volil trochu popisnější názvy než něco se zavináčem. Třeba opensuse_var
, opensuse_root
, mint_var
, mint_root
nebo něco podobného. Jinak není jasné, co se tam sdílí a proč. Kromě toho, žádná distribuce by si neměla myslet, že je na tom filesystému sama — i když tomu tak možná ve většině případů bude.
Díky moc Andreji!
Až bude čas, tak si vše zkusím a když tak se ještě doptám.
/@varProč to dělají takto? Jako jednak proč je to takto blbě pojmenované a umístěné přímo v rootu a ne schované někde v např:
/.subvolumes
, ale hlavně, jakou má výhodu mít subvolume "bokem" a potom ji mountovat do /var
, když lze mít přímo /var
jako subvolume (a nemusím to extra mountovat)? Snapshotovat a "revertovat" to můžu stále. Jediné o co přijdu je možnost to připojit s jinými parametry, další výhody nevidím.
Proč to dělají takto?
Netuším. A nelíbí se mi to.
…a ne schované někde v např: /.subvolumes…
Nebýt CDDL a nebýt faktu, že ZFS/ZoL se s každým druhým updatem kernelu nepřeloží, přesně kvůli tomuto bych už tu a tam měl na pár strojích ZFS místo Btrfs. Protože ZFS má /.subvolumes
on steroids, mírně řečeno.
ZFS má totiž oddělený filesystém filesystémů, který nezáleží na adresářové struktuře. Což je na první pohled nepodstatné, ale na druhý pohled je to asi tak to nejpodstatnější, co může být: ZFS totiž má hierarchii subvolume (inu, říká jim filesystem; každý tomu říká jinak) a v té hierarchii se dají dělat snapshoty atomické přes několik subvolume. Jo, tohle Btrfs nemá ani náhodou, protože nebyl s takovým cílem od začátku navržený a patche, které něco takového dělaly, byly zamítnuté. (Ne proto, že že by měly v nějakém slova smyslu moc těžké zamykání, ale proto, že byly prostě úplně špatně od základu (userspace vs. kernel atd.).)
Já vím, že OpenSUSE je na tom co se týká btrfs asi nejlépe, ale Mint mi vyhovuje opticky (lupa, kontrast, nastavení velikosti ikon na panelu atd.), což je pro mě primární. Ale na odkaz se určitě podívám. Díky
Pochopil jsem tě.
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.