Systém souborů Btrfs - podjednotky a snapshoty (diskuse)

[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>