Systém souborů Btrfs - podjednotky a snapshoty

19. 2. 2014 | Luboš Doležel | Různé | 7733×

V minulém díle jsme se dívali na práci s vícero zařízeními. Další zajímavý aspekt Btrfs ale funguje vlastně obráceně: podjednotky umožňují vytváření více různých systémů souborů na jediném zařízení (nebo poli zařízení). Podjednotky přinášejí řadu zajímavých možností, které jiné systémy souborů nenabízejí. Tento článek se bude věnovat právě podjednotkám a s nimi spojeným mechanismem snapshotů.

Obsah

• Základy
• Snapshoty
• Kvóty podjednotek

Základy

Typický unixový systém souborů obsahuje jediný adresářový strom s jediným kořenovým adresářem. Ve výchozím stavu je systém souborů Btrfs organizován stejně. Podjednotky tuto představu mění tím, že se vytvářejí dodatečné kořenové adresáře fungující jako nezávislé systémy souborů. Můžeme si to ukázat na jednoduchém příkladě:

# mkfs.btrfs /dev/sdb5
# mount /dev/sdb5 /mnt/1
# cd /mnt/1
# touch a

Zatím máme obyčejný systém souborů btrfs s jediným prázdným souborem (nazvaným a). Pro vytvoření podjednotky a souboru uvnitř podjednotky můžeme napsat:

    # btrfs subvolume create subv
    # touch subv/b
    # tree
    .
    ├── a
    └── subv
	└── b

    1 directory, 2 files

Podjednotka byla vytvořena s názvem subv; prozatím nejde tuto operaci rozlišit od prostého vytvoření adresáře stejného názvu. Jsou tu ale určité rozdíly, které se vynoří, když se člověk snaží. Například:

# ln a subv/
ln: failed to create hard link ‘subv/a’ => ‘a’: Invalid cross-device link

I když tedy subv vypadá jako obyčejný podadresář, systém souborů s ním zachází, jako by byl na jiném fyzickém zařízení; vstup do subv je jako přechod přes běžný unixový bod připojení [mount point], i když se stále nachází na původním systému souborů btrfs. Podjednotku lze také připojit nezávisle:

# btrfs subvolume list /mnt/1
ID 257 gen 8 top level 5 path subv
# mount -o subvolid=257 /dev/sdb5 /mnt/2
# tree /mnt/2
/mnt/2
└── b

0 directories, 1 file

Závěrem tedy je, že s každou podjednotkou se dá zacházet jako se samostatným systémem souborů. Je zcela možné vytvořit celou řadu podjednotek a každou z nich připojit nezávisle, díky čemuž pak máte sadu nezávislých systémů souborů sdílející úložné zařízení. Po vytvoření podjednotek už není potřeba připojovat „kořenové“ zařízení, jestliže vás zajímají jen podjednotky.

Btrfs bude ve výchozím stavu připojovat kořenovou jednotku, pokud mu pomocí připojovací volby subvolid= nepovíte, že tak činit nemá. Je to opravdu ale jen výchozí stav; kdybychom chtěli takto připojovat naší novou podjednotku, stačí spustit:

btrfs subvolume set-default 257 /mnt/1

Od této chvíle při připojení /dev/sdb5 bez volby subvolid= povede k připojení podjednotky subv. Kořenová jednotka má číslo nula, takže připojení subvolid=0 připojí právě kořen.

Kořeny je možné odstranit pomocí:

btrfs subvolume delete cesta

U obyčejných podjednotek (na rozdíl od snapshotů, na které se podíváme za chvilku) musí být cesta před smazáním prázdná.

Snapshoty

Snapshoty v Btrfs jsou zvláštním typem podjednotky – zachycují kopii stavu jiné podjednotky. Pokud se vrátíme k našemu jednoduchému systému souborů vytvořenému dříve:

# btrfs subvolume snapshot /mnt/1 /mnt/1/snapshot
# tree /mnt/1
/mnt/1
├── a
├── snapshot
│   ├── a
│   └── subv
└── subv
	└── b

3 directories, 3 files

Podpříkaz snapshot vytvoří snapshot dané podjednotky (kořenové jednotky /mnt/1 v tomto případě) a umístí tento snapshot pod požadovaný název (/mnt/1/snapshot) v dané podjednotce. Díky tomu máme novou podjednotku nazvanou snapshot, která zdánlivě obsahuje úplnou kopii všeho, co na systému souborů předtím bylo. Btrfs je ale systém souborů typu copy-on-write (kopíruj při zápisu), takže není nutné všechna tato data kopírovat; snapshot jednoduše vlastní referenci na aktuální kořen systému souborů. Pokud někde dojde ke změnám – buď v hlavní jednotce nebo ve snapshotu – tak bude vytvořena kopie dotčených dat, takže druhá z těchto dvou kopií zůstane nedotčena.

Všimněte si, že obsah existující podjednotky (subv) není součástí snapshotu. Pokud chcete snapshot podjednotky, musíte si jej vytvořit sami.

Snapshoty mají užitečnou roli jako záloha. Pokud má člověk linuxový systém s Btrfs, tak může vytvořit snapshot před instalací aktualizací z distribuce. Pokud aktualizace proběhnou v pořádku, tak je možné snapshot jednoduše smazat. (Mazání se dělá opět pomocí btrfs subvolume delete s tím, že snapshoty před mazáním nemusejí být prázdné.) Pokud se aktualizace ale nevyvedou, tak je možné ze snapshotu udělat výchozí podjednotku a restartovat – vše bude jako předtím.

Na takovýto nástroj se snadno zvyká. Rovněž to na pohled vypadá, že jde o oblast, kde časem vzniknou různé vysokoúrovňové nástroje. A je tomu tak, už se na nich pracuje; podívejte se například na Snapper nebo btrfs-time-machine. Před časem byla zaslána také funkce autosnap, i když se okolo ní v poslední době nic neděje. Většina uživatelů snapshotů jich tedy pravděpodobně užívá pomocí vlastních skriptů.

Kvóty podjednotek

Asi netrvá moc dlouho, než se člověk začne zabývat myšlenkou, kolik místa jednotlivé podjednotky využívají. Naivní používání nástroje jako du nepovede k získání užitečné odpovědi; du to pomalé a nebere to ohled na data sdílená mezi podjednotkami (zejména snapshoty). Navíc by bylo v mnoha případech hezké moci rozdělit jednotku na podjednotky, ale zamezit tomu, aby některá z podjednotek zabrala všechno dostupné místo. Toto se dá řešit pomocí mechanismu kvótových skupin pro podjednotky.

Než začneme, tak se sluší na pár věcí upozornit. Zaprvé, kvóty v tomto případě nejsou běžné kvóty pro celý disk; tyto je možné na Btrfs spravovat jako na každém jiném systému souborů. Kvóty podjednotek na Btrfs oproti tomu sledují a řídí využívání místa podjednotkami bez ohledu na vlastníka souborů, které místo zabírají. Zadruhé je tu pak to, že tento mechanismus je relativně nový. Nástroje pro správu jsou docela primitivní, vyskytují se problémy s výkonem a nešťastníci mohou narazit na nějaké ty problémy.

Systémy souborů Btrfs nemají kvóty standardně zapnuté. Pro zapnutí spusťte:

# btrfs quota enable cesta

Pro dodatečné přidání kvót do staršího systému souborů je potřeba více práce; více na této stránce na wiki. Jakmile máme kvóty povolené, tak se můžeme na podívat na aktuální využití pomocí:

# btrfs qgroup show /home-backup
qgroupid rfer        excl       
-------- ----        ----       
0/5      21184458752 49152      
0/277    21146079232 2872635392 
0/281    20667858944 598929408  
0/282    20731035648 499802112  
0/284    20733419520 416395264  
0/286    20765806592 661327872  
0/288    20492754944 807755776  
0/290    20672286720 427991040  
0/292    20718280704 466567168  
0/294    21184458752 49152

qgroupid je identifikátor (ve skutečnosti jde o dvojici identifikátorů – více později) dané kvótové skupiny řídící každou podjednotku, rfer je celkový objem dat, na který se v dané podjednotce odkazuje, a excl je objem dat, který není sdílen s žádnou další podjednotkou. Ve zkratce: rfer ukazuje přibližně to, co by vypsalo du, zatímco excl nám zase říká, kolik místa můžeme získat smazáním podjednotky.

...nebo tak nějak. V tomto případě je podjednotka označovaná jako 0/5 kořenovou jednotkou, kterou nelze smazat. 0/294 je posledním vytvořeným snapshotem; od aktuálního stavu systému souborů se liší jen málo, takže neobsahuje mnoho jedinečných dat. Pokud bychom smazali nějaké soubory z hlavního systému souborů, pak by objem dat v excl u posledního snapshotu narostl (soubory by stále existovaly ve snapshotu), zatímco objem volného místa na celém systému souborů by nevzrostl.

Omezení pro podjednotky můžeme nastavit pomocí příkazu:

# btrfs qgroup limit 30M /mnt/1/subv

Ozkoušet to pak můžeme takto:

# dd if=/dev/zero of=/mnt/1/subv/junk bs=10k
dd: error writing ‘junk’: Disk quota exceeded
2271+0 records in
2270+0 records out
23244800 bytes (23 MB) copied, 0.0334957 s, 694 MB/s

Račte si povšimnout, že omezení jsou jen přibližná; v tomto případě jsme nastavili limit 30 MB, ale narazili jsme na něj už při 23 MB. K tomuto dochází navzdory tomu, že systém zdánlivě zná skutečný stav:

# btrfs qgroup show -r /mnt/1
qgroupid rfer     excl     max_rfer 
-------- ----     ----     -------- 
0/5      16384    16384    0        
0/257    23261184 23261184 31457280 

Nás zajímá řádek 0/257; podle aktuálního využití jsme sice pod limitem, i tak jsme ale byli omezeni.

Je tu pak ještě jedna zajímavá komplikace, například:

# rm /mnt/1/subv/junk
rm: cannot remove ‘/mnt/1/subv/junk’: Disk quota exceeded

Ve světě copy-on-write i mazání dat vyžaduje místo na disku, tedy alespoň na chvíli. Uživatel by v této situaci byl v koncích; dokud někdo alespoň po dobu mazání souborů limit nezvedne, pak se toho příliš dělat nedá. Tento konkrétní problém je vývojářům Btrfs znám už od roku 2012, ale vypadá to, že se na opravě nepracuje.

Kvótové skupiny jsou ale mocnější, než jsme doposud mohli vidět; například je možné kvóty seskupovat do hierarchií, kde se omezení aplikují na více úrovních. Představte si, že máme systém souborů Btrfs určený mimo jiné pro domovské adresáře. Každý domovský adresář bychom nastavili jako oddělenou podjednotku:

# cd /mnt/1
# btrfs subvolume create home 
# btrfs subvolume create home/user1
# btrfs subvolume create home/user2
# btrfs subvolume create home/user3

Ve výchozím stavu je každá podjednotka ve vlastní kvótové skupině, tudíž je možné využití místa každého z uživatelů snadno omezit. Pokud jsou ale v rámci daného systému souborů i další hierarchie, tak by mohlo být pěkné moci omezit i velikost home jako celku. Nejprve bychom vytvořili novou kvótovou skupinu:

# btrfs qgroup create 1/1 home

Jak už jsme mohli vidět, tak identifikátory kvótových skupin jsou dvojicí čísel; první odpovídá úrovni skupiny v hierarchii. Na úrovni listu (koncového uzlu) je toto číslo nulové; ID na této úrovni mají jako druhé číslo v páru číslo podjednotky. Všechny vyšší úrovně jsou vytvářené administrátorem a druhé číslo u nich může být libovolné.

Hierarchii vytváříme tak, že přiřazujeme skupiny nižších úrovní do nových skupin vyšších úrovní. V našem případě mají podjednotky vytvořené pro domovské adresáře identifikátory 258, 259 a 260 (což bychom zjistili pomocí btrfs subvolume list), takže přiřazení provedeme následovně:

# btrfs qgroup assign 0/258 1/1 .
# btrfs qgroup assign 0/259 1/1 .
# btrfs qgroup assign 0/260 1/1 .

Omezení pak nastavíme takto:

# btrfs qgroup limit 5M 0/258 .
# btrfs qgroup limit 5M 0/259 .
# btrfs qgroup limit 5M 0/260 .
# btrfs qgroup limit 10M 1/1 .

Při tomto nastavení může každý z uživatelů zabrat 5 MB místa ve své vlastní podjednotce. Uživatelé jsou ale celkově omezeni na 10 MB místa, takže pokud user1 a user2 naplno využijí svých kvót, pak bude mít user3 zkrátka smůlu. Po vytvoření právě takového situace vypadá stav kvót na disku následovně:

# btrfs qgroup show -r .
qgroupid rfer     excl     max_rfer 
-------- ----     ----     -------- 
0/5      16384    16384    0        
0/257    16384    16384    0        
0/258    5189632  5189632  5242880  
0/259    5189632  5189632  5242880  
0/260    16384    16384    5242880  
1/1      10346496 10346496 10485760 

Vidíme, že ve dvou prvních uživatelských podjednotkách byla kvóta vyčerpána; to se týká i nadřazené kvótové skupiny (1/1), kterou jsme vytvořili pro celý home. Autor článku si není vědom způsobu, jak si nechat hierarchii kvótových skupin vypsat.

Jak jste sami mohli vidět, podpora kvót pro podjednotky nese známky dosti čerstvého kódu; ještě chvíli potrvá, než bude tato funkce připravena pro produkční nasazení. Podjednotky a snapshoty obecně jsou už ale k dispozici celé roky a jsou v relativně dobrém stavu. Celkově vzato jsou podjednotky velmi užitečná věc; v budoucnu se možná budeme divit, jak jsme se bez nich mohli obejít.

V tento moment jsme probrali všechny hlavní funkce Btrfs. Příště se zaměříme na několik zbývajících věcí a seriál tím bude zakončen.

       

Komentáře

[Honza Jaroš]

S tou nutností mít podjednotku práznou, když ji mažu, to asi bude trošku jinak, alespoň moje jádro 3.10 ve spojení s btrfs-progs 3.12 proti mazání neprázdné podjednotky nic nemá:

hlxc data # btrfs sub cre pokus
Create subvolume './pokus'
hlxc data # echo 1 > pokus/test.txt 
hlxc data # mkdir pokus/subdir
hlxc data # echo 1 > pokus/subdir/test.txt
hlxc data # btrfs sub del pokus
Delete subvolume '/mnt/data/pokus'
hlxc data #

[Aleš Kapica]

To je možné. Starší jádra s tím u mne také nedělala cavyky. Jádro 3.12 se ale chová popsaným způsobem.

[petr_p]

Podjednotky a snímky se tváří z hlediska VFS jako adresáře? Nebo stat(2) má pro ně nějaký nový typ?

Při vytváření se uvádí název nové cesty. Jak se vyvarovat konfliktu ve jménech souborů? Co když použiji existující název? Znamená to, že je dobré si vyhradit nějaký adresář, kam budu cpát tyto identifikátory? Je nutné při vytváření podjednotek/snímků a uvádět cestu, když vnitřně jsou stejně reprezentovány číslem? Číslem které je někdy třeba použít místo cesty. Nebylo by bezpečnější a čistší používat jen čísla? Jsou ta čísla statická, nebo se v průběhu života souborového systému mění? Je možné změnit název cesty? Pokud čísla nebo cesty lze měnit, nehrozí zde riziko souběhů?

[Heron]

Podjednotky a snímky se tváří z hlediska VFS jako adresáře? Nebo stat(2) má pro ně nějaký nový typ?

Subvolume:

root@raid:/home# stat tomas
  File: ‘tomas’
  Size: 1660            Blocks: 0          IO Block: 4096   directory
Device: 1bh/27d Inode: 256         Links: 1

Snapshot:

root@raid:/home# stat snap
  File: ‘snap’
  Size: 1660            Blocks: 0          IO Block: 4096   directory
Device: 1dh/29d Inode: 256         Links: 1

Adresář:

root@raid:/home# stat addr
  File: ‘addr’
  Size: 0               Blocks: 0          IO Block: 4096   directory
Device: 19h/25d Inode: 259         Links: 1

[wondra]

Zdravim a dekuji za clanek. Hlavne o kvotach jsem jeste nikde necetl. Nevite, zda uz funguje moznost pripojit subvolume s kompresi, zatimco root bude nekomprimovany?

[Aleš Kapica]

Autor článku si není vědom způsobu, jak si nechat hierarchii kvótových skupin vypsat.

Vyzkoušel autor také parametr -c?

stroj:~# btrfs subvolume show /btrfs-home/user1 
/btrfs-home/user1
        Name:                   user1
        uuid:                   2d064873-afac-bb49-afb3-21b1984e6607
        Parent uuid:            -
        Creation time:          2013-10-25 21:38:59
        Object ID:              509
        Generation (Gen):       17603
        Gen at creation:        813
        Parent:                 257
        Top Level:              257
        Flags:                  -
        Snapshot(s):
stroj:~# btrfs qgroup show -c /btrfs-home/user1 | grep 0/509
0/509    98086912    98086912    --- 
1/1      98618036224 98618036224 ...,0/509,...

[DIK]

Ahoj všem, když jsme u toho btrfs, dneska, po korektním restartu se mi podělal svazek o velikosti 7T, na kterém bylo dost snapshotů.

Btrfsck --repair nepomáhá.

Fedora 20 kernel 3.13 btrfsck-progs - 3.12.1.fc20 HW je Ok

Data naštěstí nejsou kritická ,ale i tak bych je rád zachránil.... Nevíte náhodou někdo co se dá s tím dělat? Díky Dik

btrfsck --repair  /dev/sda5
enabling repair mode
parent transid verify failed on 255328256 wanted 16035 found 15942
parent transid verify failed on 255328256 wanted 16035 found 15942
parent transid verify failed on 255328256 wanted 16035 found 15942
parent transid verify failed on 255328256 wanted 16035 found 15942
Ignoring transid failure
Checking filesystem on /dev/sda5
UUID: 9393db61-fb09-4a03-b6b7-3b147ca5004d
checking extents
parent transid verify failed on 283377664 wanted 16035 found 9855
parent transid verify failed on 283377664 wanted 16035 found 9855
parent transid verify failed on 283377664 wanted 16035 found 9855
parent transid verify failed on 283377664 wanted 16035 found 9855
Ignoring transid failure
parent transid verify failed on 283492352 wanted 16035 found 15539
parent transid verify failed on 283492352 wanted 16035 found 15539
parent transid verify failed on 283492352 wanted 16035 found 15539
parent transid verify failed on 283492352 wanted 16035 found 15539
Ignoring transid failure
parent transid verify failed on 283803648 wanted 16035 found 15632
parent transid verify failed on 283803648 wanted 16035 found 15632
parent transid verify failed on 283803648 wanted 16035 found 15632
parent transid verify failed on 283803648 wanted 16035 found 15632
Ignoring transid failure
parent transid verify failed on 287965184 wanted 16035 found 15942
parent transid verify failed on 287965184 wanted 16035 found 15942
parent transid verify failed on 287965184 wanted 16035 found 15942
parent transid verify failed on 287965184 wanted 16035 found 15942
Ignoring transid failure
parent transid verify failed on 293781504 wanted 16035 found 15942
parent transid verify failed on 293781504 wanted 16035 found 15942
parent transid verify failed on 305987584 wanted 16035 found 15934
parent transid verify failed on 305987584 wanted 16035 found 15934
parent transid verify failed on 305987584 wanted 16035 found 15934
parent transid verify failed on 305987584 wanted 16035 found 15934
Ignoring transid failure
btrfsck: cmds-check.c:2212: check_owner_ref: Assertion `!(rec->is_root)' failed.
Neúspěšně ukončen (SIGABRT)

[Aleš Kapica]

Já teda bych osobně nejprve zkusil příkaz check a pak rescue. Až pak bych přikročil k btrfsck.

[DIK]

...tak nakonec pomohlo mount -o recovery , a co se týče pádu FS tak za to zřejmě může komprese + velké IO. DIK

[David Jaša]

Jestli to není tím, že Fedora přešla z 3.12 na 3.13 v posledních dnech...

[sewi]

Autor clanku to bere dost povrchne. Napriklad u snapshotu vubec nezminuje, ze jsou po vytvoreni defaultne primountovany a IMHO ve verzi jadra 3.12 to nelze zmenit. Taky snapshoty nejsou nijak organizovany a jeste jsou zapisovatelne!
Par let jsem pouzival ZFS a musim rict ze co do prehlednosti a spravovatelnosti mu btrfs nesaha ani po kotniky. Nejvice se to projevi pri vetsim mnozstvi snapshotu a filesystemu. Veci jako stromova struktura snapshotu a dedicnost delaji mnohonasobne snadnejsi.

[Aleš Kapica]

Primountovany? Jste nějak mimo, ne?

[sewi]

Muzete to rozvest misto oslcovani. Ano snapshot je po vytvoreni pripojeny do filesystemu. btrfs subvolume snapshot /mybtrfs /mybtrfs/snapshot1. Nebo chcete rict, ze to jde i jinak?

[Aleš Kapica]

Jaké osočování? To že se subvolume jeví při zběžném pohledu jako adresář ještě neznamená, že je namountované. Je třeba si uvědomit, že ZFS je jiný souborový systém a Btrfs není jeho kopie. Na rozdíl od ZFS kupř. nekombinuje souborový systém s blokovými zařízeními.

Namountuje-li se nově vytvořený Btrfs souborový systém, pak se mountuje rovnou na jeho kořen. Teprve existují-li na něm subvolume, lze místo kořene mountovat subvolume.

[DIK]

samozřejmně, že nejsou namountované... DIK

[sewi]

Dukaz misto slibu. Zkousel jsem to na noteboku protoze jinde btrfs nemam. Mozna je to dilo automountu.

[root@ntb1 ~]# uname -a
Linux ntb1 3.13.3-201.fc20.x86_64 #1 SMP Fri Feb 14 19:08:32 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

[root@ntb1 ~]# btrfs sub list /
ID 256 gen 2145 top level 5 path root
ID 258 gen 2145 top level 5 path home
ID 259 gen 1217 top level 5 path srv
ID 260 gen 2147 top level 5 path var

[root@ntb1 ~]# cd /srv/

[root@ntb1 srv]# echo "testfile" > ./testfile

[root@ntb1 srv]# ll
total 4
-rw-r--r-- 1 root root 9 Feb 20 08:28 testfile

[root@ntb1 srv]# btrfs sub snapshot /srv /snapshots/srv_0
Create a snapshot of '/srv' in '/snapshots/srv_0'

[root@ntb1 srv]# cd /snapshots/

[root@ntb1 snapshots]# mount | grep btrfs
/dev/sda3 on / type btrfs (rw,relatime,ssd,discard,space_cache,autodefrag)
/dev/sda3 on /srv type btrfs (rw,relatime,ssd,discard,space_cache,autodefrag)
/dev/sda3 on /home type btrfs (rw,relatime,ssd,discard,space_cache,autodefrag)
/dev/sda3 on /var type btrfs (rw,relatime,ssd,discard,space_cache,autodefrag)

[root@ntb1 snapshots]# ll
total 0
drwxr-xr-x. 1 root root 16 Feb 20 08:28 srv_0

Trochu me prekvapilo ze mount k tomu nevraci zadnej zaznam. Mozna proto ze je to snapshot. Kazdopadne ten snapshot pripojeden je a jak je videt dole je pripojenej RW coz jde proti jakekoli logice.

[root@ntb1 snapshots]# echo "tfile" > /srv/testfile2

[root@ntb1 snapshots]# ll /srv
total 8
-rw-r--r-- 1 root root 9 Feb 20 08:28 testfile
-rw-r--r-- 1 root root 6 Feb 20 08:31 testfile2

[root@ntb1 snapshots]# ll /snapshots/srv_0/
total 4
-rw-r--r-- 1 root root 9 Feb 20 08:28 testfile

[root@ntb1 snapshots]# echo "adding" >> /snapshots/srv_0/testfile 

[root@ntb1 snapshots]# cat /srv/testfile
testfile

[root@ntb1 snapshots]# cat /snapshots/srv_0/testfile 
testfile
adding

[Honza Jaroš]

Jestli to nebude tím, že se nic nemountuje, prostě to je součást filesystemu stejně jako třeba adresář...

Jinak pokud chcete read-only snapshot, stačí ho vytvářet s parametrem -r

[sewi]

O -r parametru jsem uz slysel ale default je RW a to je spatne. A z v mych ocich je takhle spatne navrzeny cely btrfs. Treba neschopnost spocitat obsazene misto per subvolume a dalsi.

[Aleš Kapica]

Prohlašovat o něčem co neznám že je špatně navržené je z mého pohledu poněkud schrecklich.

[Heron]

O -r parametru jsem uz slysel ale default je RW a to je spatne.

Proč by to mělo být apriori špatně?

[Aleš Kapica]

Nevím jestli to není zbytečné se opakovat, ale po lopatě.

Vy máte Btrfs systém nad jedním fyzickým zařízením. Ten je namountován na kořen /. Adresáře root, home, srv a var ve skutečnosti nejsou adresáře, ale subvolume, takže lze vůči nim dělat snapshoty. Kromě nich však máte na kořeni i adresáře a mezi jinými také adresář snapshot, do kterého jste udělal snapshot srv_0 subvolume /srv. To je celé.

Pravda. Trochu mi uniká, proč máte mountované ty čtyři zmíněné subvolume, když to není nutné, ale to bude možná věcí distribuce - jednoduchou změnou ve fstabu tak lze místo nich namountovat právě vytvořený snapshot.

Jinak k tomu že do snapshotu lze zapisovat - snapshoty se s parametrem -r dají vytvořit i jako "readonly". A někdy je vytvoření readonly snapshotu dokonce podmínkou pro další operace.

[sewi]

Udelal jsem to tak sam po vzoru zfs, kde / a /home jsou ruzne filesystemy a /home muze mit jine parametry - kompresi, deduplikaci, noatime. V btrfs to tak taky funguje takze v tom navrhu nevidim nic spatneho ale je to jen test prostredi na notebooku. Ohledne snapshotu - Muzete mi prozradit validni duvod proc mit RW snapshot (teda krome toho ze si vyvojari rekli, ze by to bylo fajn a ze to prece dokazou)?

[Heron]

Tak vy můžete mít vytvořený btrfs s několika subvolume a každý z nich mít připojený s jinými paramtetry. Kořen toho BTRFS nemusíte mít nutně připojený nikam. Mít kořen btrfs připojený na kořen a potom do něj připojovat jednotlivé subvolume z toho samého btrfs je tak trochu nelogické (i když ne nemožné).

K těm snapshotům, máte na vybranou, zda mít RW či RO. RO je nutnou podmínkou pro send. RW jsou praktičtější pro běžnou práci. Já to běžně používám, pokud si chci něco vyzkoušet. Udělám si snapshot nějakého aktuálního stavu, tam si hraju s věcmi, které bych na "ostrou" subvolume nedělal a pokud to nevyjde, tak ten snapshot prostě smažu. Proč je RW default vám neřeknu, ale podlě mě je to celkem jedno (kdo chce RO, může ho mít).

[Heron]

Udelal jsem to tak sam po vzoru zfs

BTRFS není ZFS. Dělat něco po vzoru něčeho jiného není vždy ta nejlepší cesta k úspěchu. I mě, po letech s BTRFS připadají některé věci od ZFS nelogické (například práce s více diskovými zařízeními), ale kritizovat to nehodlám, k tomu bych si musel nastudovat celé ZFS a pochopit jeho vnitřní logiku a návrh.

[Honza Jaroš]

Tak tak.

<ironie>V ZFS mi chybí možnost zmenšovat svazky, takže je špatně navržené...</ironie>

[Muctlandly]

We wrote a tutorial for ETrade users that want to login to the website. etrade login After you experience ETrade login screen, you'll see that.