Dotaz: Migrace z ext4 na Btrfs

[Petr Fiedler]

Zdravím,
jak většina z vás ví, pořizuji si nový desktop. Stávající jsem už prodal, ale než jsem to udělal, udělal jsem si Clonezillou zálohu. Disk byl rozdělen takto:

sda  500 GB
sda1 500 MB EFI                FAT
sda2 100 GB /rootfs LUKS + LVM ext4
sda3 zbytek /data   LUKS       Btrfs

Teď si chci pořídit NVMe 1 TB a mám to namyšleno takto:

sda    1 TB
sda1   1 GB EFI                       FAT
sda2 200 GB /rootfs (@/ + @/home) LUKS Btrfs
sda3 zbytek /data                LUKS Btrfs

Mám takovou představu, že bych tu zálohu obnovil na sekundární HDD, pak bych na tom NVMe vytvořil 1 GB EFI oddíl, 200 GB LUKS+Btrfs oddíl a zbytek ~800 GB LUKS+Btrfs /data oddíl pro oddělená data. A pak bych zkopíroval EFI z HDD na NVMe a stejně tak i /rootfs. Chci se zeptat, jestli to nějak půjde zrealizovat? Pokud ano, byl bych rád, kdyby mi sem někdo napsal seznam všech kroků a já už bych si s tím snad nějak poradil.

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

Ještě jsem si uvědomil, že jsem zapomněl na swap, takž bych na NVMe místo 200 GB oddíl udělal 250 GB oddíl a vytvořil tam 50 GB swap.

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

Odpovědi

[GeorgeWH]

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

Tak to IMHO nechapes zmysel volumov/subvolumov (ci ako sa to v btrfs vola).

vytvořil tam 50 GB swap

OMG!!!

[Max]

Musíš mít ještě třetí partition pro boot.

sda1 (600MB) /boot/EFI (FAT32 EFI)
sda2 (600MB) /boot
sda3 (luks)

Vytvoříš LUKS, ten si pak otevřeš/odemkneš jako např. "datastore" (= /dev/mapper/datastore). A ten datastore pak naformátuješ na btrfs.
V rámci btrfs si pak vytvoříš subvolumy, já používám dvě (jednu pro systém, jednu pro home). fstab pak bude vypadat takto:

...
/dev/mapper/datastore   /        btrfs    defaults,subvol=system         0      0
/dev/mapper/datastore   /home    btrfs    defaults,subvol=home           0      0
...

btrfs podporuje swap, takže pokud budeš chtít swap, tak si vytvoř soubor na btrfs a vypneš u něj CoW:

fallocate /swap.img -l 4g
chattr +C /swap.img
mkswap /swap.img

V rámci grubu si pak ještě uprav default settings:

# /etc/default/grub
...
GRUB_ENABLE_CRYPTODISK=y
...

Já používám arch linux, tam je třeba ještě říci, co vše má být součástí intramdisku + následně jej přegenerovat

#/etc/mkinitcpio.conf
...
HOOKS="base udev autodetect keyboard keymap consolefont modconf block encrypt lvm2 filesystems mdadm_udev"
...

Pokud by tvá deska měla problém najít na EFI partition tvůj zavaděč (grubx64.efi), tak máš dvě možnosti řešení:
1) překopeš to na adresářovou strukturu Windows, takže to nebude "EFI/ubuntu/grubx64.efi", ale "EFI/BOOT/bootx64.efi"
2) necháš vlastní linux strukturu a zaregistruješ si OS do UEFI pomocí linux nástroje "efibootmgr"

A to je z toho základu asi vše. Pak se to bude chovat tak, že při bootu se tě to zeptá na heslo.
Migraci samotného OS asi nemá cenu zmiňovat, tam není nic nového.

Zdar Max

[Max]

Jinak jak už tady padlo, vytvářet si oddělené partition a na obou mít luks a btrfs je nesmysl. vytvoříš jednu, nad tím luks a poté btrfs + subvolumy a swap jako soubor bez CoW přímo na btrfs. Tzn., že potřebuješ jen tři partition.
Zdar Max

[Petr Fiedler]

Já si nemyslím, že je to nesmysl. Možná mi ale něco uniká. Když pominu EFI, mám teď 2 oddíly - /rootfs a /data. Oba jsou šifrované. Už se mi několikrát stalo, že jsem musel obnovit OS a data tak zůstala v bezpečí. Samozřejmě je mám několikrát zálohovaná, ale i tak mi přijde lepší obnovovat 100 GB, než 500 GB. A u NVMe 1 TB by to byl 1 celý TB. Zálohy chci verzovat. Pořizuji si na to 4 TB HDD. Když budu mít 3 poslední verze zálohy OS, tak to je velký rozdíl, když budou zabírat 600 GB, nebo 3 TB. Na ten disk se ještě musí vejít verzované zálohy nb, RPi, OS na flešce a ještě i data. Nepřijde mi to takto špatné. 800 GB na data mi stačí a kdybych nedělal ten swap, tak 200 GB na systém + snapshoty by mělo stačit.

[Max]

Nerozumím. Pokud chceš obnovit jen systém, tak obnovíš jen systém. Pokud zálohuješ formou nějaké bitové kopie, tak je přeci ale pořád možné obnovit jen systém (=připojíš si bitovou kopii a vykopíruješ z ní data). Ale to je tvá věc. Dva oddíly = potřeba více místa a horší space management. Z tohoto systému dělení jsem u přešel i u Windows, kde mám data i systém na stejném oddíle jednoduše proto, protože není problém obnovit cokoli a jakkoli.
Zdar Max

[k3dAR]

protoze btrfs nepouzivam, tak mozna placnu hloupost, ale predpokladam ze v jeho pojeti by nezalohoval celej oddil clonezilou, ale konretni subvolume by poslal na zalohovaci stroj pres "btrfs send" a zaroven by na cilovem disku byla deduplikace, takze by to ani nezabralo 3x obsazene_subvolume ale pouze 1x celek + 2x pouze_rozdily...

[Petr Fiedler]

Tak to zní zajímavě. Pokud by to tak bylo, tak to by bylo super.

[Heron]

Pokud by byl na cílovém disku taky btrfs, tak lze dělat inkrementální snapshoty a tedy posílat pouze změny od minulého snapshotu. A mít tak na cílovém disku klidně celou historii snapshotů.

Ale je filozofickou otázkou, zda mít na zálohovacím médiu stejný fs jako na zálohovaném. Když se zrovna rozbije driver, tak to může zničit oba. Proto mám zásadně na zálohách jiný fs, než na zálohovaném stroji.

[Petr Fiedler]

A nešlo by mít cíle dva, na první s Btrfs posílat inkrementální snapshoty a z něj rsyncovat na druhý cíl např. se ZFS?

[Heron]

To samozřejmě lze, jsou to prostě soubory

[k3dAR]

pokud pouzije (a on chce) misto Grub "zavadec" Sicherboot(resp. to je "jen" pripravatorske skripty pro vlastni klice a baleni initrd+jadra do efi binarky a podepisovani, jinak je to v podstate systemd-boot zavadec), tak je vhodnejsi pouzit EFI oddil vetsi, obzvlast kdyz by krome distribucniho jadra chtel pouzivat (a on chce) "ubuntu kernel mainline", tak aby nemusel porad odmazavat starsi a mel vic "casu" tak EFI proste to 1GB jak psal :)

umoznuje swap file na btrfs hibernaci na disk? (to nevim jestli chce)

ze je zbytecne mit 2 oddily s LUKS a nad tim BTRFS asi souhlasim, leda ze by chtel mit moznost zamknout datovej oddil pri odemcenem systemu (at uz z jakehokoliv duvodu)

oddeleny boot by potreboval proc? pri pouziti Grub a btrfs pro rootfs? pri pouziti Grub a LUKS/LVM/EXT4_ROOTFS vim ze neni oddeleny boot potreba, pri pouziti Sicherboot + LUKS/LVM/EXT4_ROOTFS take ne, NEvim jak s btrfs, ale minimalne s Sicherboot si myslim ze take nebude potreba, protoze to z EFI oddilu nacte EFI binarku s jadro+initrd, a rootfs pripojuje tedy uz inicializovanej initrd...

[Max]

Tak to jsem jeho dotaz asi špatně pochopil, nikde jsem si nevšiml, že chce použít Sicherboot, proto jsem popsal standardní cestu s grubem.
Tak v tom případě pak samozřejmě oddělený boot nepotřebuje.
Zdar Max

[k3dAR]

na Sicherboot mel dotaz predtim
tedy pro info, s grub+luks/btrfs je oddelenej boot potreba?

[Max]

Mám to podle klasiky tak, že na EFI je Grub. Pokud máš na EFI kernel s initrd v EFI formátu, tak asi samo problém nebude. Každopádně já třeba nechci mít kernel na blbý FATce a chci mít někde (na hlavním PC to tak nemám) Grub pro jednodušší dualboot s Win. Pravdou ale je, že Sicherboot neznám, všude jedu Grub a zatím nevidím důvod ke změně.
Zdar Max

[Petr Fiedler]

nechci mít kernel na blbý FATce

Kvůli právům, nebo proč?

[Max]

Už jen samotný fakt, že se musí používat FAT32 mi je proti srsti. Pokud máš navíc dualboot s win, tak máš kernel s initrd jednoduše přístupný i z těch win, což se mi také příčí.
Pokud máš boot zvlášť, tak může být též naformátovaný na btrfs a čerpat z toho pak benefity toho fs.
Zdar Max

[k3dAR]

no Grub na EFI chapu, ale nechapu zda je nutne mit oddeleny boot pri rootfs na LUKS/BTRFS, protoze kdyz sem mel Grub a rootfs na LUKS/LVM/EXT4, tak oddelenej boot sem nemel/nechtel, nebylo to potreba, Grub odemknul LUKS, aktivoval LVM a initrd a jadro si natahlo z neoddelenho/zasifrovaneho /boot z rootfs...

s Sicherboot kdy mam jadro+initrd v efi binarce jde o to ze sice je dostupne, ale je podepsane vlastnim klicem, v UEFI jsou smazane vychozi/MS klice a jsou tam pouze me, takze podvrhnout to nelze (krome samozrejme resetu/reflashi biosu s vypnutim SecureBoot)

[Josef Kufner]

Grub má pomalou implementaci LUKS, takže odemykání trvá dlouho. Ale jinak jo, teoreticky to enní potřeba. Prakticky je Grub nahrazen EFI a Sicherboot to kompletně pořeší bez /boot při bootu, jen to ještě není default po instalaci.

[k3dAR]

sicherboot uz roky pouzivam, ale ma otazka byla konkretne zda s Grub a LUKS/BTRFS je nutny oddeleny/nesifrovany boot

[Josef Kufner]

Není to nutné – Grub to přečte, ale pomalu.

[k3dAR]

jo taak, to souviselo s tim proc oddelenej/nesifrovanej boot :) nicmene pak Max zaroven zbytecne nastavuje GRUB_ENABLE_CRYPTODISK

[Max]

Je to tak a není to tak. Třeba už mám špatnou paměť a doma už boot nemám, už nevím, musím se podívat. Řešil jsem to 2x a je to nějaký pátek a obě mašiny jsou různé, jedna má UEFI, druhá ne atd.
Zdar Max

[lertimir]

No přečte to rychle, pomalu odvozuje klíč. Když zadáváš v cryptsetup klíč do slotu LUKSu specifikuješ -i čas, ve kterém má strávit iteriacemi PBKDF2 než z hesla otevře master key. ten čas se počítá s HM podporou, kterou cryptsetup samozřejmě dělá, grub ji nemá, tak to počítá dlouho. Já to řeším tak, že mám iterace krátké a dlouhé hesla. Pro hlavní disky 30+ znaků. když máš komplexitu v hesle útočníkovi by stejně rychle vyhodnocování nepomohlo.

[Josef Kufner]

= přečte, ale pomalu.

A zbytečně snižovat bezpečnost mi nepřijde vhodné.

[lertimir]

To není snižování bezpečnosti. Pokud máš entropii hesla řekněme 10^8 a 1000ms PBKDF2 a když budeš mít místo toho heslo 10^12 a 10ms PBKDF2 tak máš bezpečnost vyšší.

[Petr Fiedler]

Já používám heslo o délce 35 znaků. Jakou hodnotu by bylo dobré nastavit pro tu iteraci?

[Petr Fiedler]

O Sicherbootu jsem v dotazu nic nepsal, ale Radek ví, že jej chci. Pokud tedy půjde na novém desktopu zprovoznit. Na nb se mi to nepovedlo/nejde to.

[hemmond]

Co se týče /boot partition zvlášť, tak po přechodu na BTRFS jsem zjistil, že mít /boot na rootfs na BTRFS je problém - GRUB tam při bootu nedokáže zapsat - takže nelze používat věci jako GRUB_SAVEDEFAULT.

* https://askubuntu.com/questions/148662/how-to-get-grub2-to-remember-last-choice

* https://forum.manjaro.org/t/grub-error-sparse-file-not-allowed/20267

[Aleš Kapica]

Co to je za blbost?!

[hemmond]

Jak to myslíte? To co jsem popsal, jsem vypozoroval, když jsem přecházel z kubuntu na EXT4 na BTRFS. Na EXT4 byla /boot jen složka na / partišně. Po překopírování dat a přegenerování GRUB konfiguráku se začalo objevovat "Sparse file not allowed" (které se přestalo objevovat při vypnutí SAVEDEFAULT funkce Grubu - což ovšem nebyl požadovaný stav), a aby tato funkce fungovala, musel jsem vytvořit novou partišnu /boot a přesunout na ni obsah složky /boot z root partišny.

[Aleš Kapica]

Ta u *buntu je možné všechno, že. Ale rozhodně to není problém Grubu.

Ty evidentně nevíš, o co jde.

[Aleš Kapica]

Ne. Opravdu nevím.

https://www.gnu.org/software/grub/manual/grub/grub.html#Environment-block

[Aleš Kapica]

A na co by mi to bylo?

No tobě třeba na nic, ale někomu se to může hodit, jako třeba předřečníkovi. A ty mu místo toho píšeš něco o blbostech a že to není problém grubu, i když nevíš wocogo.

[k3dAR]

ne, opravdu nevis... tvuj odkaz neresi problem s SAVEDEFAULT + BTRFS o kterem predrecnik psal...
zminuje se ale o nem napr. ArchWiki:

GRUB_SAVEDEFAULT=true
This will only work if /boot is not a btrfs, because grub cannot write to btrfs.
But it will generate a misleading error message: "sparse file not allowed. Press any key to continue.".

[Aleš Kapica]

To ovšem není problém Btrfs. Je to prostě způsob, jakým Grub řeší ukládání nějakého stavu. Podle mě je to teda naprostá pitomost, která akorát komplikuje život. Opravdu si nedokážu představit modelovou situaci, kdy bych něco takového chtěl, protože bych tím ztratil kontrolu nad tím co se mi kdy spustí.

Děkujeme za zhodnocení.

Ty si zřejmě myslíš, že když si ty neumíš představit, k čemu by to bylo dobré tobě, tak že z toho vyplývá, že se nemohou najít jiní, kterým by to k něčemu dobré bylo. Ne, opravdu to z toho nevyplývá. Takoví lidé evidentně existují, nezávisle na tobě.

Kromě toho, tebou používané argumenty jsou, mírně řečeno, nekorektní:

Co to je za blbost?!

Ta u *buntu je možné všechno, že. Ale rozhodně to není problém Grubu.

To ovšem není problém Btrfs.

Jo a na tom tebou odkazovaném serveru je expirovaný certifikát.

[Aleš Kapica]

Jo a na tom tebou odkazovaném serveru je expirovaný certifikát.

Já vím. Je to shoda náhodu, ale zrovna dnes ho budu přesouvat na jinou doménu a IP adresu, takže řešit nový certifikát pro stávající doménu nemělo smysl.

[Aleš Kapica]

Klíčové je, že to nesouvisí s Btrfs. Je to featura Grubu, a podle toho co píšou v manuálu použitelná jen s některými typy FS. Ovšem její smysl mi fakt uniká. Co bych s ní získal? Pokud najíždím více různých instalací, chci mít kontrolu nad tím co se mi spouší. Jaký přínos má to, že si grub uloží poslední volbu, kterou mi pak nabízí jako default? Podobné brykule dělá fastboot, což je to první co vypínám. Ostatně, není to tak dávno, co chtěl jeden pitomec reklamovat asi 20 počítačů, protože se chovaly při spouštění nedeterministicky. Přitom stačilo vypnout jen tuhle volbu. Představa že do toho ještě vstoupí podobný mechanismus na straně Grubu mne upřímně děsí.

No tak třeba já jsem to používal při bootování vzdáleného routeru při upgradu. Konfigurace 1 - stará fungující instalace, 2 - nová instalace, minimální konfigurace, na kterou se dalo ještě vzdáleně přihlásit, 3 - nová instalace, plně nakonfigurovaná pro testování. Bootovalo to postupně 3, 2, 1, 1, 1,... Když jsem se po bootu nové instalace nepřihlásil v časovém limitu pomocí ssh, tak to rebootovalo do další konfigurace. A k tomu potřeboval grub zapisovat na /boot/grub už v průběhu bootování.

Také se to dá používat na desktopu, pokud máš víc možností na bootování, že si grub zapamatuje, co jsi bootoval naposled a při rebootu bez interakce to prostě zopakuje.

Takže možnosti použití tady jsou.

[Aleš Kapica]

Já vím k čemu se to dá použít. Každopádně ale dík za reálný příklad s tím routerem. Ovšem to je tak specifické nasazení, které si vyloženě říká o oddělený logický oddíl s grubem. Na ten bych ovšem v žádném případě nedával Btrfs. Já na to používám ext2 a to především z toho důvodu, že je to jednoduchý fs, s pidiovladačem. Využívám toho u disklessových standalone serverů. Jde o malý virtuální disk (cca 100MB), na kterém je grub a jádro s ramdiskem, zpropagovaný přes NFS. Obejdu se tím bez funkčního PXE.

Ovšem to je tak specifické nasazení, které si vyloženě říká o oddělený logický oddíl s grubem.

Já na těch routerech používám debian live, takže moje instalace je miniaturní (flash) disk s ext2, adresář s grubem a adresář s live debianem, ve kterém jsou asi 4 soubory. V případě reinstalace byly ty debianí adresáře dva, stará a nová instalace. Oddělený grub by tam také vlastně mohl být. Tak to používám všude jinde.

[Aleš Kapica]

Ještě k tomu proč ne Btrfs. Základní struktura Btrfs je tak velká, že jeho použití dává smysl až od 1GB výše. A jelikož vyžaduje větší ovladač, tak Grubu nestačí 512B MBR. Použití GPT v tomto případě také postrádá smysl. Jenom by se tím komplikovala situace. Takže používám MS-DOS tabulku. Je to malé, rychlé a bezproblémové.

Pro flash disk nedává Btrfs také smysl. Není to SSD disk. Řešil bych to asi tak, že bych přes loop spouštěl squashované instalace, přeplácnuté RAM diskem. Ale to je možná tak jak to máš.

Pro flash disk nedává Btrfs také smysl. Není to SSD disk. Řešil bych to asi tak, že bych přes loop spouštěl squashované instalace, přeplácnuté RAM diskem. Ale to je možná tak jak to máš.

Přesně tak. To už není o btrfs. Moje instalace debianu live jsou dva soubory - vmlinuz a initramfs. To je celý systém. Základní konfigurace (to je ta, aby se na to dalo aspoň přihlásit) je v grubu v parametrech předávaných jádru. Provozní konfigurace je ve squashfs souboru a celé je to spojeno do ramdisku, takže se do toho dá zapisovat. Ale konfigurace se ukládá jenom zcela výjimečně, ručně.

[Aleš Kapica]

Tak já to mám dotažené ještě o kousek dál. Ale to není řešení použitelné na router. V konfiguraci zavaděče je uvedeno pouze jádro a ramdisk. Během zavádění si to pak stahuje konfigurační soubor z nějž se teprve dozví co, z jakých zdrojů a s jakou konfigurací má sestavit.

[Heron]

Doporučuju ti si btrfs vyzkoušet bokem a nanečisto. A opustit tyhle debilní názvy pro subvolume. Ukazuje to základní nepochopení konceptu subvolume (nemyslím tvoje, ale těch, kdo tohle propagují).

BTRFS tak jak je vytvořený, automaticky obsahuje jednu default subvolume tj ta, co se připojí jako kořen tohoto fs. Tj po vytvoření mkfs.btrfs a připojení se to prostě tváří jako kterýkoliv jiný FS, "system rootfs" subvolume není potřeba speciálně vytvářet, už tam prostě je.

Potom si tam můžeš vytvářet další subvolume jednoduše pomocí btrfs sub create a chovat se k nim prostě jako k adresářům. Vůbec není potřeba je pojmenovávat nějak extra nebo je někam připojovat ve fstabu. Toto je asi nejzákladnější rada. Kdykoliv cítíš potřebu, že s tím adresářem budeš pracovat jako s nějakým celkem, budeš jej chtít snapshotovat nebo samostatně zálohovat (btrfs send), tak místo mkdir prostě použij btrfs sub create.

Tj já to dělám tak, že nechám OS nainstalovat na jeden btrfs oddíl (tj disk je rozdělen na boot, efi a zbytek pro btrfs) a potom si tam vytvořím subvolume pro /data /data/projekty /data/projekty/project1 - projectX - co projekt, to subvolume. S tím, že potom mám jejich samostatné snapshoty automaticky vytvářené tak často, jak chci.

/home nedává sám o sobě smysl (ale klidně může být), daleko užitečnější jsou subvolume homes jednotlivých uživatelů. Tj po instalaci si vytvořím uživatele tomas a za jeho home zvolím předem manuálně připravenou subvolume /home/tomas.

To znamená, že ve fstabu je pro btrfs jeden řádek. Ten původní, který tam vytvořil instalátor. Přesto mám tisíce subvolumes.

Ve vytváření subvolumes někde bokem a jejich mountování každé zvlášť nedává příliš smysl. Ano, může to mít výhody v tom, že si zvolím speciální mount parametry, ale to jednak není příliš časté, ale hlavně to můžu udělat i v tom mém případě výše, pokud se pro to rozhodnu.

Swap nepoužívat. Nevím, co s tím zrovna v roce 2021 všichni začínají blbnout (viz i jiné diskusní vlákno), swap nepoužívám nikdy a nikde už 10+let. Základem je dostatek paměti, což podle ostatních diskusních vláken ty budeš hravě splňovat. Ono i to nvme je 20x pomalejší, než ramka. A nechat 50GB programů žít ve swapu, to stejně nepojede.

Takže za mě, zálohovat si ta data z té ext4 někam, nechat OS nainstalovat na jeden btrfs oddíl (a čím jednodušeji, tím lépe, tj ať se k tomu chová jako ke starému dumb fs) a rozdělit si to na subvolume podle libosti a nahrát si data tam kam patří. Za mě je to nejjednodušší cesta, která ponechává adminovi největší svobodu.

[xxl]

Tady je na serveru kernel.org k rozdělení btrfs disku něco napsáno.

Já tedy používám ten Heronem nedoporučovaný způsob rozdělení. Ale mám s tím určitě mnohem menší zkušenosti než on.

[Heron]

Ano, můj způsob odpovídá tomu nested.

Ten Flat podle mě v lidech evokuje představu, že subvolume je něco těžkotonážního. Že se to musí vytvořit na nějakém speciálním místě, že se to musí mountovat, dávat do fstabu a vůbec s tím pracovat jako se starými oddíly (ve skutečnosti spousta článků říká přesně to). Tj celkově ti lidé budou mít jinou představu a budou těch subvolume mít méně.

Já naopak chci vzbudit představu, že subvolume jen adresář s výhodami. Že to není nic těžkopádného, ale že je to na každodenní používání. Chci si něco vyzkoušet, udělám btrfs sub create. Chci předělat data (já nevím třeba hromadná změna metada u mediálních souborů), snadno si udělám snapshot. Snapshot není nic jiného, než subvolume, takže v tom můžu dělat další změny. Vlastně chci evokovat představu "správy verzí" pro velké binární soubory. Že jsou kompletně nezávislé, takže mě nemusí vůbec zajímat minulost toho kterého subvolume a můžu je libovolně promazávat.

Pochopitelně, tohle všechno můžu klidně provádět i u té flat hierarchie. V každém tom oddílu si můžu dál hrát s btrfs libovolným způsobem. Ale ve skutečnosti jsem tohle v tomto typu článků nikde neviděl. Tam se to fakt bere jako o něco málo lepší oddíly.

[xxl]

Když jsem instaloval poprvé systém na btrfs root, tak jsem to dělal pomocí debianího instalátoru, který to nainstaloval nested způsobem, protože to jinak neumí (ani v bullseye). To je skutečně jako bych to bylo na defaultním ext4, vůbec žádný rozdíl, pouze jeden parametr ve fstabu.

Ale pak jsem přemýšlel nad tím, jak budu dělat časové snapshoty, případně se k nim vracet a co to udělá s tou nested strukturou, až jsem to přeinstaloval na flat. To je tedy v debianu pěkně otravné. A zatím to tak používám. Nicméně mám vždycky jenom pár připojených subvolumes, takže to ve fstabu jde.

[LarryL]

Ale pak jsem přemýšlel nad tím, jak budu dělat časové snapshoty, případně se k nim vracet a co to udělá s tou nested strukturou,

Můžeš to trochu rozvést v čem jsou pro tebe snapshoty lepší na Flatu než na Nested. Chci taky přecházet na btrfs a zajímají mě různé pohledy, abych si udělal představu jak to chci používat. Dík.

[xxl]

No především jsem nepochopil, kam v nested struktuře budu dělat snapshoty rootfs. Dále co to udělá se subvolumy vytvořenými někde v adresářové struktuře rootfs, když budu chtít namontovat snapshot rootfs.

Nepochybně bych si s tím nějak poradil, ale to, co by mi z toho vzniklo, by se patrně podezřele podobalo flat struktuře, akorát poněkud zmatené. Takže jsem to zavrhl a zvolil flat rovnou při instalaci.

Hledal jsem na internetu nějaké příklady, ale jediné smysluplné povídání bylo to, co jsem odkazoval o kus výš.

A když si přečtu, co o btrfs píše v diskusích Andrej, který bych řekl, že se v tom vyzná, tak mi z toho vyplývá, i když on to přímo nepíše, že používá flat strukturu taky.

[Heron]

No především jsem nepochopil, kam v nested struktuře budu dělat snapshoty rootfs.

Úplně stejně jako kteréhokoliv jiné. rootfs je subvolume vytvářená mkfs.btrfs, subvolid 5. To nás ale nemusí zajímat. Lze udělat snapshot:

btrfs sub snap / /snap/2021-02-25_rootfs

a tento si potom někam poslat (btrfs send)

Potom, když tohle někde rozbalím (btrfs receive), tak získám stejný obraz rootfs jako na zdrojovém disku.

Btrfs neumí dělat rekursivní snapshoty, takže tímto způsobem vznikne skutečně jen záloha rootfs a všechny subvolume v ní budou prázdné. Proto taky můžu bez problémů dělat snapshot subvolume a pojmenovat ji cestou do této subvolume (tj / snapshotuju do /snap a není to problém).

Tj potom si tam ještě musím obnovit /home/tomas apod. Tj mám nezávislé zálohy rootfs a homes.

Ano, tady má jistou výhodu flat nebo mixed (ono je to reálně stejně všechno mixed) struktura, protože tam si můžu zvolit který rootfs chci zrovna namountovat a všechny ostatní subvolume se mi budou stále mountovat správně, protože mají svůj záznam v fstabu. Ale to u nested zvládnu taky, btrfs si umí zvolit default subvolume pro rootfs, od výroby je to subvolid5, ale lze to změnit pomocí btrfs sub set-default.

Ono je to taky o tom, co od toho kdo očekává. Já jsem rootfs nikdy neobnovoval a k vůli tomu btrfs ani nemám. Btrfs mám pro data a možnost si snadno vytáhnout mnou smazaný soubor z půlnočního snapshotu. Ještě nikdy se mi os nerozbil tak, abych musel obnovovat rootfs z image a kdyby to nastalo, tak to asi stejně nainstaluju znovu, protože po 10+letech si to ten os stejně zaslouží.

[xxl]

Díky za odpověď. V podstatě mi potvrdila, že jsem pro moje použití btrfs zvolil tu správnou strukturu.

"btrfs sub set-default" jsem neznal.

Taky běžně nerozbíjím rootfs, abych nutně potřeboval bootovat z posledního snapshotu. Ale občas se mi při upgradu distribuce novou instalací hodí, že mohu bootovat starou i novou verzi. A když to pak použiji, tak prostě potřebuji mít ve fstabu na správné místo připojené správné subvolumy, takže tam těch několik řádků je. A v nested struktuře bych měl maglajs.

Mimochodem, jak se tady jinde píše o odděleném /boot. Boot se mi osvědčil jako součást rootfs, ale používám oddělený grub.

[LarryL]

Otázka pro tebe nebo Herona: Mám ve VM Fedoru 33 s defaultní instalací Btrfs. A rozdělení je takové:

btrfs subvolume list /
ID 256 gen 7182 top level 5 path home
ID 258 gen 3948 top level 5 path root
ID 265 gen 3907 top level 258 path root/var/lib/machines
ID 267 gen 3944 top level 258 path root/.snapshots
ID 268 gen 1434 top level 267 path root/.snapshots/1/snapshot
ID 275 gen 3375 top level 267 path root/.snapshots/2/snapshot
ID 276 gen 3387 top level 267 path root/.snapshots/3/snapshot
ID 277 gen 3822 top level 267 path root/.snapshots/4/snapshot
ID 278 gen 3942 top level 267 path root/.snapshots/5/snapshot
ID 279 gen 3596 top level 267 path root/.snapshots/6/snapshot
ID 280 gen 3691 top level 267 path root/.snapshots/7/snapshot
ID 281 gen 3905 top level 267 path root/.snapshots/8/snapshot
ID 282 gen 3942 top level 267 path root/.snapshots/9/snapshot
ID 283 gen 7182 top level 267 path root/.snapshots/10/snapshot

cat /etc/fstab
UUID=d34ba215-514d-4a13-90c5-df0d5b40b4ae /                       btrfs   subvol=root,x-systemd.device-timeout=0 0 0
UUID=2033a11a-4a29-46de-80ca-d47d1c1c1572 /boot                   ext4    defaults        1 2
UUID=46AB-E178                            /boot/efi               vfat    umask=0077,shortname=winnt 0 2
UUID=d34ba215-514d-4a13-90c5-df0d5b40b4ae /home                   btrfs   subvol=home,x-systemd.device-timeout=0 0 0

btrfs subvol list / | cut -f9 -d' ' | sed -e 's/^/ROOT\//' | paths2indent | indent2tree
ROOT
├── home
└── root
    ├── var
    │   └── lib
    │       └── machines
    └── .snapshots
        ├── 3
        │   └── snapshot
        ├── 9
        │   └── snapshot
        ├── 2
        │   └── snapshot
        ├── 1
        │   └── snapshot
        ├── 7
        │   └── snapshot
        ├── 5
        │   └── snapshot
        ├── 10
        │   └── snapshot
        ├── 8
        │   └── snapshot
        ├── 6
        │   └── snapshot
        └── 4
            └── snapshot

Chápu správně, že to je Flat struktura?

PS: Poslední script je odtud.

[Heron]

Jo, tohle je flat. Ve skutečnosti ale mixed, protože kdybys tam měl nspawn kontejnery (v /var/lib/machines), tak jednotlivé kontejnery budou na subvolume a nepřepokládám, že by to pro každý z nich vytvářelo řádek v fstabu.

OT: Mimochodem, tohle je taky docela sranda, když jsem přenášel kontejnery pomocí příkazů machinectl export-tar, import-tar, tak při importu zatarovaného kontejneru na nový stroj, kde nebyl btrfs (schválně), tak vytvořil image na disku, naformátoval jako btrfs a namountoval právě do /var/lib/machines. Což je docela úsměvné, protože nspawn vůbec nevyžaduje btrfs a kontejner vesele běží normálně z adresáře. Ale nástroje tvrdošíjně vytvářejí btrfs i takto podivným způsobem. Takže jsem to nakonec přenesl jako soubory a normálně pustil.

[pet I.]

Když jsem na notebooku začal s btrfs, udělal jsem si /root a /home subvolumy. Pravidelně je zálohuju (mám Gentoo, tam má záloha /root před updatem smysl ) a send|receive je kopíruju na velký externí disk. Když jsem si zkusil udělat subvolumy v hloubce stromu, sice to fungovalo, ale přestal jsem mít přehled co jsou adresáře a co subvolumy. Tak jsem je přesunul (normální mv) do / a buď je používám přímo tam, nebo si je přimountuju kam potřebuju.

Nested / Flat je pouze o organizaci subvolumu, buď je dáváš na jedno místo, nebo je vhodně označíš/registruješ, třeba je speciálně nazveš (@ na začátku).

[LarryL]

ale přestal jsem mít přehled co jsou adresáře a co subvolumy.

Toho se taky obávám. Když Heron psal, že subvolume je adresář s výhodami, tak to znělo lákavě, ale mít úplně pomíchané subvolume a obyč. adresáře by asi byl zmatek.

třeba je speciálně nazveš (@ na začátku)

Ano, asi je to pro rychlou přehlednost nejjednodušší varianta.

[Josef Kufner]

… A pak jednoho dne koukneš na zálohy a divíš se, že tam půlka věcí není, neboť byla v subvolume a ten snapshot to nevzal, neboť není rekurzivní.

[LarryL]

No to jo, to by se klidně mohlo stát. Takže chaotické vytváření subvolumes si škrtám

[k3dAR]

no ja ti nevim je preci jedno zda zapomenes pri snapshotu /data :
- ze /data/neco je subvolume
nebo
- ze /data/neco je mountpoint z subvolume

to jake a kde mam subvolume muzu zjisit:
- btrfs sub list
nebo
- kouknutim do fstab ci "mount | grep ..." (ci do jednotneho dir kam subvolume vytvarim)

prijde mi to v podstate stejne prehledne, ale u nested se nemusi resit pripojovani...

[LarryL]

- ze /data/neco je mountpoint z subvolume

No šak ani mountpointy by se neměly vytvářet bezhlavě po celém disku. Pro pořádek je taky lepší je dávat třeba do /mnt nebo do /home/user. Vlastně si nevzpomínám, že bych někdy vytvářel mountpoint jinde než na těch dvou místech.

[Petr Fiedler]

Já datový oddíl připojuji do /data, protože podle dokumentace se do /media připojují flešky, ext. HDD atp (ikona na ploše) a /mnt slouží pro dočasné připojení třeba adresářů. A protože se mi datový oddíl připojuje automaticky po startu a je připojen celou dobu, ani jeden z těch dvou přípojných bodu se pro připojení nehodí.

[LarryL]

Já datový oddíl připojuji do /data

Jo taky dobrá varianta. Já jsem tenkrát četl, že i home je dobré umístění a už jsem u toho zůstal.

[k3dAR]

no prave :) pak mi ale "nevyhoda" vytvaret subvol uz v cilenem miste nepripada horsi nez tam z centralniho montovat, oboje se da snadno vylistovat :)

[LarryL]

Nejsem si jistý co mi chceš říct. Možná jsi mi jen nerozuměl: Proti subvol v cíleném místě nic nemám. Zavrhl jsem pouze chaotické vytváření subvol na mnoha různých místech.

[k3dAR]

ano, nerozumel :) za "chaoticke" sem myslel ze povazujes prave to v cilenem misto v centralnim+mount :)

[Heron]

Ale já nenavrhuju náhodně míchat adresáře a subvolume. Vzhledem k tomu, že btrfs neumí rekurzivní snapshoty, tak projekt, který chci snapshotovat jako celek už celkem logicky nemá žádné další subvolume obsahovat. Tj nestane se mi, jak upozorňuje Josef, že s překvapením zjistím, že nějaká subvolume není na zálohách. Ve skutečnosti je to právě naopak, tento btrfs systém používám právě pro zálohy. Tj pokud se chce projekt dostat do záloh, tak to musí být subvolume a musí se snapshotovat. (Úplně stejně to dělám na FreeBSD a ZFS. Zálohuju jenom pomocí zfs send)

Tj mám jednotlivé homes jako suby, potom jednotlivé projekty jako suby, potom jednotlivé nwpawn kontejnery jako suby, potom pro každou skupinu dat jako sub apod. Tj ty subvolume mám na celkem očekávatelných místech, kde jsem si je takto vytvořil.

K tomu mám v cronu (systemd.timeru) skript, který každou půlnoc udělá denní snapshoty v každém tom jednotlivém umístění subvolume. Tj mám /home/.snap/2021-02-24_tomas, kde je snapshot mého home vzhledem k tomu, že se mi to nechce mazat, tak to mám až do roku 2019). A totéž pro kontejnery a projekty. Tj každou noc se vytvoří několik desítek snapshotů. (Ano, píšu noc, protože toto mám na domácním servříku, ale to je jedno.)

Předpokládám, že i s obyč. adresáři nemáš data náhodně rozsypaná po disku, ale místo toho máš třeba něco jako workplace s projekty (nebo já nevím co děláš, tj pouze příklad). Vlastně se to dá říct i jinak, tam, kde pro malé věci používám git, tak pro velké používám btrfs. A projekty v gitu taky nemám na náhodných místech, ale v adresáři ~/git, golang věci v ~/go apod.

Asi je lepší si to fakt zkusit, věnovat tomu jeden víkend, a přijdeš na to rychleji než z popisu v diskusi.

[LarryL]

Ale já nenavrhuju náhodně míchat adresáře a subvolume.

Já vím, ale jak jsi to srovnával s adresářem, tak to ve mne vyvolalo dojem, že pokaždé když budu chtít nad jakýmkoliv adresářem dělat hokus-pokusy, tak z něj vytvořím subvolume, ale teď už si uvědomuji, že v tom musí být nějaký řád.

jednotlivé projekty jako suby

Jen se ještě zeptám. Jakou má výhodu mít jednotlivé projekty jako suby a nemít jen nadřazený adresář jako sub? Pokud se ti dělají snapshoty cronem, tak u vytváření snapshotů to asi žádnou výhodu nemá, takže to asi má výhodu jen při obnovování subvolume ze snapshotu ze zálohy z důvodu, že je to rychlejší?

[Heron]

Jen se ještě zeptám. Jakou má výhodu mít jednotlivé projekty jako suby a nemít jen nadřazený adresář jako sub? Pokud se ti dělají snapshoty cronem, tak u vytváření snapshotů to asi žádnou výhodu nemá, takže to asi má výhodu jen při obnovování subvolume ze snapshotu ze zálohy z důvodu, že je to rychlejší?

Tak jde hlavně o pořádek. Když v archivu najdu zálohu pojmenovanou 2016-02-26.nspawn.gallery2.btrfs(.xz), tak vím přesně co to obsahuje. Když tam budu mít 2016-02-26.kontejnery.btrfs, tak mi to vůbec nic neřekne. Nehledě na to, že obsah toho hlavního adresáře se může neustále měnit (a taky se mění), takže zálohovat prostě jen "projekty" nemá smysl, protože záloha "projekty" teď a za týden může obsahovat zcela jiné věci. Je to zkrátka něco podobného jako u git repositáře, tam by měly být také pouze věci týkající se nějakého celku a nic navíc.

Navíc ty snapshoty se nemusí vytvářet jen cronem. Pokud na něčem dělám "hokus-pokusy", tak si vytvářím po každém kroku snapshot. Tj každý projekt má jinou granularitu snapshotů. Ty lze navíc nezávisle mazat, takže u některých projektů je klidně promažu více, u některých si třeba chci nechat delší historii. Je to velmi užitečné u těch kontejnerů, protože když něco testuju a instaluju neznámou appku, tak si po každém kroku udělám snap, kdybych něco zvojtil, tak ať se můžu snadno vrátit.

[LarryL]

Ano, dává to smysl co píšeš, takže se tím budu inspirovat. Dík.

[LarryL]

... V jiném komentu od tebe čtu větu:

(Toto je další důvod pro použití subvolume: pokud vím, že budu pracovat s velmi mnoha soubory, tak je lepší to potom smazat jako celek, protože na rm bych taky mohl čekat několik dnů.)

Takže už začínám chápat, že subvolume pro jednotlivé projekty má i jiné výhody než jen při snapshotech.

[k3dAR]

swap pouzivam protoze hibernuju na disk (nevim jak Petr bude chtit s stolnim PC), takze samzorejme jina moznost neni (a ne neni ani alternativa suspend do ram)...

s pristupem nic nemountovat a vytvaret subvolumes primo v miste kde je chci, je zajimave info diky, existuje pak nejakej zpusob (bez skriptovani) zobrazit kde jsou jake subvolumes v ramci celeho stromu?

ad oddelenem boot, psal sem se uz nahore Maxe, ale zeptam se i tebe, PROC oddelenej boot?

[Heron]

swap pouzivam protoze hibernuju na disk

OK. Já ne, protože:

$ systemd-analyze 
Startup finished in 4.671s (kernel) + 3.078s (userspace) = 7.749s 
graphical.target reached after 3.066s in userspace

Ve skutečnosti mnohem déle trvá POST (a grub) než samotný boot linuxu a všechny programy, které používám, si pamatují předchozí session, takže to není žádný problém. Zapnu PC a do 20s jsem na pracovní ploše. Start FF se všemi taby netrvá ani 2s. A kdyby se mi chtělo, tak si v i3wm nastavím start všech základních programů, které obvykle používám. Problém je v tom "obvykle". Obvykle ani nechci startovat do stavu, v jakém jsem to vypínal (tj hibernoval).

s pristupem nic nemountovat a vytvaret subvolumes primo v miste kde je chci, je zajimave info diky

Dyť to takhle píšu už od roku 2011... Fakt si to prostě někde nanečisto vyzkoušejte.

existuje pak nejakej zpusob (bez skriptovani) zobrazit kde jsou jake subvolumes v ramci celeho stromu

Seznam subvolumes je btrfs sub list /path, má to milion přepínačů a ve skutečnosti to pouštím pouze tehdy, kdy se někdo zeptá na podobnou otázku, tj ve skutečnosti jsem to nikdy nepotřeboval. Subvolumes vytvářené "jako adresáře" se nikdy neztratí z dohledu, vždy budou viditelné na nějaké cestě, kde to uživatel buď vytvořil nebo následně přejmenoval.

ad oddelenem boot, psal sem se uz nahore Maxe, ale zeptam se i tebe, PROC oddelenej boot?

Ve skutečnosti to až tak moc neřeším, takže nejlepší odpověď je že nevím, ale mám dual boot (widle) a nevím, jestli by to šlo nějak vyšperkovat a upřímně v tom ani nevidím přínos. Dual boot funguje, instalátor to správně detekoval, víc neřeším.

[k3dAR]

s hibernaci mi urcite nejde o rychlost startu, klidne by misto asi 30s to mohlo byt 5minut ale jde mi o zachovani stavu vseho, i toho co nepodporuje obnovu stavu po "rebootu", treba i Vivaldi kterej sice otevrene taby obnovi, tak s 15 oknama s 200listama preci jen trva tak 1m nez se to po startu probere, dale treba v terminalu mam byobu (ala screen/tmux) rozdelene na 10 "stranek", kazde tak po 2-6 suboknech a i kdyz pouzivam pro byobu save/restore tak to neni 100% a pak treba Mousepad, resp, proste dalsi programy co nepodporuji ulozeni "session"...

ad "btrfs sub list" diky, pouzivat btrfs tak mi to asi dojde z helpu, ale overeno je to presne co sem chtel a co bych "potreboval"(pro svoji prehlednost) kdyz bych subvolume nemontoval :)

[LarryL]

Subvolumes vytvářené "jako adresáře" se nikdy neztratí z dohledu, vždy budou viditelné na nějaké cestě, kde to uživatel buď vytvořil nebo následně přejmenoval.

Jsem zvyklý používat Thunar, tak se chci zeptat jestli existuje nějaký grafický správce souborů ve kterém by byly graficky odlišené obyčejné adresáře a subvolumes, abych třeba věděl zda pro daný "adresář" mohu vytvářet snapshoty.

Předpokládám, že ve správci souborů nepůjde subvolumes smazat jako běžný soubor, ale bude se to muset dělat třeba přes Service Menu, které je např. v Doplhinu.

[k3dAR]

to service menu by v "ramci moznosti" asi slo udelat i v Thunaru pres vlastni akce, ale neslo by poznat zda "adresar" je subvolume nebo ne, takze by to zobrazovalo vsem dir, nebo to omezit podle masky, coz by ale neslo pri nepouzivani @subvol jmena, nevim jak to ma Doplhin, v tom z tveho odkazu vidim ze delete akce si kontroluje zda jde o subvolume nez ji zkusi mazat, takze to mozna take zobrazuje vsem "dir" :)

[k3dAR]

odliseni subvol v Thunaru pak manualne, kdyz udelas subvol, tak ji v Thunaru priradit emblem :))

[Petr Fiedler]

Nebo prostě v názvu použít na začátku "@".

[Heron]

Jsem zvyklý používat Thunar, tak se chci zeptat jestli existuje nějaký grafický správce souborů ve kterém by byly graficky odlišené obyčejné adresáře a subvolumes

Nevím o tom (což neznamená, že neexistuje). Já pracuju více na řádce.

abych třeba věděl zda pro daný "adresář" mohu vytvářet snapshoty

Tak asi je lepší udržovat strukturu dat tak, aby to bylo zcela jasné. Ono zase vytvářet subvolume bezhlavě kdekoliv nemá moc smysl.

Předpokládám, že ve správci souborů nepůjde subvolumes smazat jako běžný soubor, ale bude se to muset dělat třeba přes Service Menu, které je např. v Doplhinu.

Ano.

[Petr Fiedler]

Díky za perfektní komentář a vysvětlení.

Mě není jasné, kdy/jak se subvolumes vytváří. Nainstaluji OS tak, jak to udělá instalátor Mintu. Ten při použití Btrfs udělá @/ a @/home (@ nechme stranou). A já teď v tom čerstvě nainstalovaném OS smažu vše v @/ a zkopíruji tam vše ze zálohy kromě /home? A do @/home pak ten obsah /home? A kdybych chtěl např. subvolume @/opt, tak bych při kopírování / ze zálohy do @/ vynechal ještě /opt a pak vše z /opt zkopíroval do @/opt? Chápu to správně?

A jak to vlastně kopírovat. Asi to bude rsync skoro se všemi parametry co existují, co? Já na vše používám pouze sudo cp -a a to by v tomto případě asi nestačilo.

[Heron]

Mě není jasné, kdy/jak se subvolumes vytváří.

rootfs subvolid 5 se vytvoří při mkfs.btrfs. Další subvolume vznikají příkazem btrfs subvolume create (příkazy lze zkracovat, takže lze psát btrfs sub create apod.).

Co vytváří instalátor Mintu nevím, k tomu se nebudu vyjadřovat.

A já teď v tom čerstvě nainstalovaném OS smažu vše v @/ a zkopíruji tam vše ze zálohy kromě /home? A do @/home pak ten obsah /home? A kdybych chtěl např. subvolume @/opt, tak bych při kopírování / ze zálohy do @/ vynechal ještě /opt a pak vše z /opt zkopíroval do @/opt? Chápu to správně?

No já asi nechápu co má být cílem? Nainstalovat OS a potom všechno smazat a kopírovat tam cosi jiného je přece zbytečný krok. Stejně nakonec budeš muset řešit boot. Takže jestli to chceš řešit takto kompletně manuálně, tak si můžeš vytvořit čistý btrfs, tam si nakopírovat OS (a přesně jak píšeš, pořešit práva a xattr apod, takže správně nastavený rsync), ten kopírovaný OS musí být připraven na boot z btrfs, to znamená, že v initrd už musí být schopen namountovat btrfs. A následně ještě pořešit boot.

Jako nevím, proč to dělat takto složitě, není jednodušší si nainstalovat čistý OS a nastavit si vše znovu i podle zálohy? Tj některé konkrétní konfiguráky si vzít ze zálohy /etc, home si tam nakopíruješ asi celý apod.

[Andrej]

@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í.

[tak toto]

smysl hibernace (a swapu) uniká

Nekdo rad vypina stroj kdyz ho prenasi v batohu aby ho neuvaril, neplencal baterii, treba kdyz nekam najednou pospicha a nema cas nebo nechce pozavirat vsechno co otevrel. To pochopis, typicky byznysman. Ikdyz byznysmanu s destopovym linuxem asi moc nebude ne-li zadny, to je pravda.

[Max]

A jak notebook uvařím, když je ve sleepu v ramce? Vždyt skoro 99% je vypnutých a netopí to.
Zdar Max

[j]

A co se asi tak stane, az tomu notesu za 3,4 hodky dojde baterka. Aha, proste chcipne.

---

Dete s tim guuglem dopice!

[lertimir]

Ale to ho dávám do usnout tak 5% baterky. normální současný notebook vydrží ve sleepu alespoň týden. to vydrží i muj starý z původní baterkou z roku 15.

[Andrej]

Tvůj příspěvek pochází zjevně z roku 2000 nebo tak. Těžko říct, jak se mohl ocitnout v tomhle vlákně.

Dnes máme rok 2021. Dnešní běžný notebook vydrží uspaný do paměti asi tak měsíc, pročež se nemá jak přehřát v batohu. Tolik tepla najednou zkrátka negeneruje, aby se uspaný přehřál nebo aby v dohledné době vybil baterii. (Když notebook používám a dobíjím každý pracovní den, co je mi do toho, že by mu po měsíci spánku mohla dojít baterie?)

Tak proto^^^ je uspáni na disk (hibernace) v dnešní době v podstatě nepotřebná záležitost.

Jediná výhoda hibernace je vyšší odolnost proti cold boot útokům, protože uspání do RAM je pro cold boot útok přímo ideální situace.

Nicméně pokud notebook neukládá ultra-hyper-kriticky-tajná data (nebo pokud se dokáže při uspání do RAM dočasně zbavit podstatných klíčů), je hibernace fakt všeho všudy buržoasní přežitek.

[Peter Golis]

Dnešný NB síce vydrží uspatý mesiac. Ale neprebudí sa ak napríklad touchpad chytí interferenciu z mobilu a interpretuje si ju ako dotyk prstom (pohnutie myškou)? To by stačilo mať ruksak v batohu, a pri takomto prebudení sa ten NB uvarí. Pár krát mi to v zime vyhrievalo chrbát, a NB sa potom natvrdo vypol.

[Max]

Co to bylo za model?
Zdar Max

[Tom K]

Mě něco podobného v posledních dvou letech udělaly dva notebooky. Dell z roku 2018 (na linuxu) a Macbook Air z roku 2019 (na OSX).
Oba to udělaly několikrát (méně než desetkrát, více než dvakrát).

[Peter Golis]

Yop, chyba ACPI keď sa Notebook chce prebudiť pomocou touchpadu ak je notebook zaklapnutý a touchpad je fyzicky nedostupný. A touchpad zachytí el.smog napr. z mobilu.

Keby to robila externá myška, tak nič nepoviem. To je žiadúca funkcionalita keďže dosť ľudí používa NB v podobnej polohe (dock, klávesnica, myš, externý monitor a zaklapnutý displej aby nezavadzal na stole). Ale môze to urobiť podobný problém ak rádioprijímač myšky obdrží šum z BT ktorý interpretuje ako pohyb, alebo myška nebola vypnutá.

[k3dAR]

tvuj NB co vydzi 3 tydny v sleep2ram
- nema vlastnosti ktere od NB pozaduju (primarne Thinkpad classic klavesnice)
- kdyz je uspanej tak ma predpokladam odemcenej LUKS, takze pripadnej bug v screensaveru ci cemkoliv co brani utocnikovi rovnou ziskat data, by znamenal ziskat pristup k souborum ktere chci mit sifrovane... + LUKS klic je asi v pameti, takze teoreticky lze z ni take ziskat

jinej duvod proc pouzivam swap v podstate nemam, nepotrebuju vice "RAM" nez mam fyzicky RAM, resp. parkrat se SWAP hodil kdyz sem pustil nejake virtualy a nevsiml si ze sem jine zapomel vypnout, tedy situace ze par GB vlezlo do swapu...(nikoliv ze by nejaky program zabiral "RAM" donekonecna takze by zaplnil stejne za chvilku i SWAP)

[Andrej]

Lpění na noteboocích z archeologických nalezišť (které mají tu jedinou správnou klávesnici atd.) nepovažuju za validní argument.

Souhlasím, že se cosi se v poslední dekádě zhoršilo, pokud jde o klávenice notebooků. (Výměnou za to jsou ale notebooky tenčí a lehčí.)

Doma i ve dřině mám prostě Thunderbolt dock s monitorem klávesnicí podle nejdivočejších představ. (Klidně mi ta klávesnice umí [[odstraněno pro hrubé porušení pravidel komunity]].)

Klávesnice notebooku je taková nouzovka do vlaku a tam mi přijde spíš vhod, že je klávesnice malá, tenká, podsvícená, lehká atd., byť pro dlouhodobou dřinu nepohodlná.

Zkrátka a dobře, každý dnešní notebook ty 3 týdny uspání do RAM vydrží. Ten, který našli vedle Věstonické venuše, možná tu hibernaci ještě potřebuje.

[jen tak]

každý dnešní notebook

Jak casto kupujes notebook a posledni mas z roku, prvni jsi zaplatil sam?

... mam tady konvertibilni notebook podrobim ho zkousce ve Fedora 33, pokud ho tedy predem nepovazujes za fosilii? Jen doufam, ze se vubec probudi, ze tam nebude nejaky bug (a neprijdu o neulozenou ulohu kdyz to budu muset restartovat), zkusenosti z drivejska, ironie na zacatek ;), tak pokud to schvalis?

[k3dAR]

Pokud mi Thinkpad T430s (i7 3gen, 16GB RAM, SSD 512GB, 14" FHD IPS, WWAN LTE, WifiAC, BT4) vyhovuje, nevidim problem s tim ze Andrej ho povazuje za archeologickej nalez klavesnici v tom mam z T420, ZADNEJ dnesni NB by mi nesplnil to co od nej ocekavam, takze tvoje blbe kecy jsou jen k smichu externi klavesnici mam pouze u desktopu a je to klavesnice totozna s T420, nicmene u NB pouzivam jeho interni klavesnici, at uz je NB v docku, nebo ne, pouzivani externi klavesnice je to totiz "moda" lidi co maji NB s novodobou nekvalitni klavesnici kazdopadne o problematice uspani do ram s odemcenym LUKS sem psal jinde...

[Petr Fiedler]

Na desktopu od swapu tedy upouštím. Uvědomil jsem si, že na něm uspávám pouze od RAM.

A dělit tedy asi taky nebudu. Vzhledem k tomu, co napsal Max a k3dAR to asi není třeba.

Ohledně překopírování systému vím, že to je fuška. Zkusil jsem si to nasimulovat. Na sekundárním disku jsem si pomocí GParted vytvořil EFI oddíl a oddíl pro /rootfs, pak jsem nainstaloval Mint nad Btrfs. Pak jsem pomocí sudo cp -a překopíroval vše z /rootfs jinam. Pak jsem ten oddíl znovu naformátoval a zašifroval, odemknul, pomocí sudo cp -a vše vrátil zpět, upravil /etc/defaul/grub, vytvořil /etc/crypttab, odpojil zamknul, znovu odemknul pod názvem z /etc/crypttab, chrootnul, ale update-grub mi vždy končil chybou. Update-initramfs mi prošel. Teď si uvědomuji, že jsem asi měl ještě dát klíč do slotu. Každopádně místo cp -a by to asi chtělo rsync, ale ten já neznám a man page má 4k stránek. To je pro mě i kvůli angličtině neschůdné. Chtěl jsem se právě vyhnout nové instalaci, ale asi nevyhnu.

[LarryL]

Chtěl jsem se právě vyhnout nové instalaci, ale asi nevyhnu.

Pokud bys přeinstalovával a chtěl si ušetřit čas instalací balíčků, tak i u vás na Mintu jde udělat hromadný export nainstalovaných balíčků a hromadná instalace. Pokud teda je možnost spustit Mint z té zálohy co máš, abys udělal export.

[Petr Fiedler]

Instalace balíčků není problém. Problém je konfigurace.

Jinak díky. To jsem neznal. Podívám se na to.

[k3dAR]

nebo pouzit primo apt-clone

[Petr Fiedler]

To je oboje super. Ve VM zkusím.

[k3dAR]

ten apt-clone dela i to ze pribali pridane repositare vcetne jejich podpisu a v pripade ze mas nainstalovane neco co uz nemas dostupny repositar (nebo si *.deb instaloval rucne) je dokaze prebalit do deb a vlozit do vystupniho archivu (parametr --with-dpkg-repack pripadne bez nej ti ho po exportu oznami pokud najde neco zminovaneho)

[Reinhard]

Neotravuj ho, zkousi. Zdrzel jsi ho uz min. o hodinu!

[j]

Zas pises ty svoje kraviny? Swap v souboru je uplne napicu!

Jednak je to nejmin o rad pomalejsi druhak s tim polovina veci co od toho lidi chteji nefunguje ze?

"swapu v kombinaci s SSD je sporná záležitost, vzhledem k možnosti rychlého opotřebení SSD"

Megablabol roku! Vazneni,neberte tenhle chorej mozek vubec vazne. Nez se SSD osoupe, budete si vybirat svuj drevenej futral. Provozuju nekolik stovek SSD od desktopu pres servery a diskovy pole, a po cca 5-7letech, kdy se prevazne vyrazujou, je jejich "osoupanost" na maximalne 15%.

To je o nekolik radu pravdepodobnejsi, ze proste znicehoz nic chcipne.

---

Dete s tim guuglem dopice!

[Aleš Kapica]

Přesně tak. Zrovna předevčírem byl za mnou na radu chlapík, co používá všude ubuntu, že se mu to vždycky začne časem brutálně zpomalovat. Nejdřív mě to nenapadlo, protože Debian by default tuhle zhůvěřilost nepoužívá. No a pochopitelně že to byla příčina problému.

[k3dAR]

reagujes na "swapfile je pomalej"? pouzivam Xubuntu ale s swap lv a necekal bych problem s swapfile kvuli pomalosti, ale kvuli problematickemu(/ctejsimu) uspavani na disk :)

[Aleš Kapica]

Ne že je pomalý, ale že je z principu na hovno. Protože kdy systém začne swapowat? No když mu dochází paměť. A pokud to začne swapovat do souboru v rámci nějakého žurnálovacího FS. Tak to zvedne co? No? IO operace FS a ty žerou co? No CPU výkon a.. paměť. Takže se tím situace ještě víc zkomplikuje. Takže buď si nechávat na discích místo pro swap (klidně to může být více menších swapů na více discích). Nebo ho zrušit. Ovšem pak je nutné si uvědomit že v dnešní době nenažraných aplikací holt někdy něco nedoběhne a spadne. Já používám dva menší swapy na SSD. Protože mám stejně BTRFS v raid 1, takže na každém disku mám kus vyhrazený pro swap (asi 32GB)

Protože mám stejně BTRFS v raid 1

a btrfs neumí swapfile na filesystému vytvořeném nad více než jedním diskem.

[Aleš Kapica]

Nejsem idiot, abych swapoval na COW systém, takže by mě ani nenapadlo něco takového od něj očekávat.

Ten jednotlivej fajl si můžeš označkovat jako nocow, takže na btrfs vytvořeném z právě jednoho disku klidně můžeš swapfile mít. Ale na btrfs ze dvou a více disků to nefunguje.

[Aleš Kapica]

Znovu opakuji a připomínám výchozí premisu vlákna. Nejsem idiot, abych swapoval na jakýkoliv FS. Pokud používáš swapovací oddíl, tak se na něj prostě vybleje kus RAM a jede se dál. Kdežto v případě swapování do souboru na FS do toho vstupují další operace, které vyžadují spolupráci s RAM. Je to fakt tak velký problém tohle pochopit?

[LarryL]

Kdežto v případě swapování do souboru na FS do toho vstupují další operace, které vyžadují spolupráci s RAM.

Podle mě si kernel namapuje bloky ve swapfile a pracuje přímo s nimi. Když chceš hibernovat do swapfile, tak musíš také zadat resume_offset= do grubu, takže rozdíl ve výkonu mezi používání swapfile a swappartition nebude. Ale pokud je nějaký odkaz na benchtest, který dokazuje opak, tak nemám problém uznat, že máš pravdu.

[LarryL]

...mimochodem v maillistu na to odpověděl Andrew Morton:

> 3. Does creating the swapfile on a journaled filesystem (e.g. ext3 or > reiser) incur a significant performance hit?

None at all. The kernel generates a map of swap offset -> disk blocks at swapon time and from then on uses that map to perform swap I/O directly against the underlying disk queue, bypassing all caching, metadata and filesystem code.

[Aleš Kapica]

Mimochodem. Dostal jsi tím odpověď i na otázku, proč se při dlouhodobějším použití zpomalují widle. Ty totiž také swapují do souboru.

No, já jsem se na nic takového neptal. Ale moje Windowsy se nezpomalují. Restartuji je tehdy, když to vyžaduje nějaká aktualizace. Jinak je pouze uspávám. A úplně stejně používám také Linux. Nicméně v podstatě ten swap nepotřebuji ve Windows ani v Linuxu.

[Robert]

Dostal jsi tím odpověď i na otázku, proč se při dlouhodobějším použití zpomalují widle.

To ale podložené nemáš viď, jen domněnka? Zpomalovaly se s fragmentací ale od SSD už nemám zkušenost, ty ano?

[k3dAR]

jasne, no ja nad tim ani vubec nepremyslel, kdyz prislo *buntu s swapfile, tak sem si jen rekl "to je ale blbost" a pripravil si swap-lv :) (i ciste install, u povysovanejch nebylo co resit, tam uz swap-lv bylo a instalator swapfile nenutil)

LV může být rozházené po disku úplně stejně, jako swapfile. Z tohoto hlediska je nejlepší mít pro swap vyhrazenou partition. Ale o kolik je to rychlejší, to je otázka.

[k3dAR]

rozhazene nemam, swam mam v 1 segmentu, pokud by ho nekdo vytvarel uz do "deraveho" lvm, tak muze pouzit volbu "--alloc contiguous", pripadne by to melo jit snad i zmenit stavajicimu lv... vyhoda swap v lv je to ze je nad LUKS(nebo neni potreba delat druhy LUKS pro SWAP), lze menit velikost podle potreby, atd :)

[LarryL]

rozházené po disku úplně stejně, jako swapfile

swapfile bys měl rozházený zřejmě jen v případě, že bys ho vytvářel na zaplněném disku kde by ho nešlo vytvořit vcelku. Pokud swapfile vytvoříš hned při instalaci (bez fragmentace), tak "na tom místě" swapfile zůstává pořád a nefragmentuje se. Když jsem se už před mnoha lety rozhodoval jestli swapfile nebo partišna, tak nakonec vyhrál swapfile, protože měl více výhod.

[tak toto]

byl bych rád, kdyby mi sem někdo napsal seznam všech kroků a já už bych si s tím snad nějak poradil

Dobrej navrh :D