Administrace komentářů

@Andrej z Mordoru:
Dělit rozhodně budu.

Chyba. Ale když už, doporučuji aspoň udělat tu menší z možných chyb: Swap má být soubor, ne oddíl. Swapovací soubor je nesrovnatelně flexibilnější.

Kromě toho bych poznamenal, že v posledních cca 10 letech jsem swap nepoužil a nepotřeboval, protože:

1. „Swapování“ (v té nejdůležitější podobě) funguje i bez swapovacích oddílů a souborů (viz podrobnosti níže).
2. Použití swapu v kombinaci s SSD je sporná záležitost, vzhledem k možnosti rychlého opotřebení SSD a jejich nízké latenci, kvůli které si uživatel problémů s pamětí nemusí včas všimnout a nečekaně se tak připravit o podstatou část životnosti SSD za krátkou dobu.
3. Použití swapu znamená, že je potřeba víc RAM, která dnes už není zdaleka tak omezená a nedostupná jako kdysi. (A pokud se swap téměř nikdy nepoužije, k čemu tam vlastně je?)
   • Ano, swap se dá použít k hibernaci, ale můj notebook vydrží uspaný do RAM víc než 3 týdny (a asi i déle, jen jsem to nezkoušel), pročež mi smysl hibernace (a swapu) uniká.

K prvnímu tvrzení výše bych rád dovysvětlil, že swapovací soubor nebo oddíl se v kofiguraci kernelu (celkem správně) jmenuje paging of anonymous memory. To ale znamená, že nenanonymní paměť, tj. ta, která pochází z mmap() a která má za prdelí úložiště (ve kterém je mmap()ovaná binárka, (kni)hovna nebo soubor, ke kterému se přistupuje přes mmap() (tj. každý soubor; kernel nemanipuluje se soubory nijak jinak než přes mmap() a stará API typu read() už jenom předstírají, že existují)) se dá vždy „odswapovat“ (tedy, odstranit z RAM ve prospěch něčeho důležitějšího) a později zase načíst zpátky, když je to potřeba. Proto absence swapovacího souboru nebo oddílu (kterou vřele doporučuji!) rozhodně neznamená, že se SSD/disk nepoužívá (v případě nedostatku RAM) místo RAM. Právě naopak, používá se, ba dokonce i mnohem bezpečněji (ve smyslu opotřebení SSD (nebo i disků)) a smysluplněji (z hlediska dlouhodobé udržitelnosti takového režimu provozu), než kdyby swapovací soubor či oddíl byl k dispozici.

…200 GB LUKS+Btrfs oddíl a zbytek ~800 GB LUKS+Btrfs /data oddíl pro oddělená data…

Proč ne raději subvolume s kvótami, které se dají (v případě dočasné potřeby) změnit?

A jak by to bylo s vytvořením subvolumes @/ a @/home?

btrfs subvolume create ...

Mimochodem, ten zavináč je taková podivná libůstka a konvence některých distribucí; nic zásadního na něm nezávisí a nic se tak jmenovat nemusí. Já většinou pojmenovávám subvolume třeba jménodistribuce_očekávanýmountpoint nebo tak, takže třeba arch_home, arch_root a podobně. Ale to už je spíš věc „vkusu“.

Jinak zkopírování něčeho na úrovni filesystému s (opravdu) všemi možnými libůstkami typu extended attributes a POSIX ACL je docela fuška. Tohle může být inspirace, ale furt to nemusí být všechno a jistě to není future-proof.

Proto vždy vřele doporučuji spíš btrfs send ... | btrfs receive ..., což zaručuje, že cokoliv, co filesystém ukládá, se přenese. (Ale pochopitelně to nepřichází v úvahu při kopírování mezi různými filesystémy atd. Jo, bylo by hyper, kdyby například mezi zfs send / receive a btrfs send / receive existovala nějaká konverze, ale zatím (pokud vím) nic takového není.