Systém souborů Btrfs - funkce send/receive a ioctl

6. 3. 2014 | Luboš Doležel | Různé | 3709×

V minulých dílech seriálu jsme pokryli většinu funkčnosti tohoto moderního systému souborů. Tento článek je tedy posledním dílem a pokrývá několik zbytků. Podíváme se na funkčnost send/receive a na některé dostupné ioctl().

Obsah

• Send/receive
• Povely přes ioctl()
• Závěr seriálu

Send/receive

Pomocí podjednotek a snapshotů je možné udělat jednoduché schéma pro tvorbu přírůstkových záloh. Například tak, že použijeme rsync k tomu, aby záložní systém souborů vypadal jako originál, a pak uděláme snapshot zálohy, aby byl zachován stav v daný čas. Tento přístup je poměrně efektivní; rsync zkopíruje pouze změny (přeskočí nezměněné soubory) a každý snapshot uchová tyto změny bez kopírování nezměněných dat. Tímto způsobem můžeme uchovávat docela rozsáhlou historii ve snadno přístupné podobě.

Existuje ale i jiný způsob, jak dělat zálohy, pokud jsou zdrojový a cílový systém souborů oba Btrfs. V tomto případě se dá mechanismus send/receive použít k optimalizaci celého procesu. Nejprve si uděláme snapshot původního systému souborů:

btrfs subvolume snapshot -r zdrojová-podjednotka název-snapshotu

Název snapshotu by pravděpodobně mohl obsahovat i časové razítko, jelikož celý mechanismus závisí na existenci snapshotů v čase každé inkrementální zálohy. Počáteční snapshot je pak okopírován na záložní jednotku příkazem:

cd záložní-systém-souborů
btrfs send cesta-k-snapshotu | btrfs receive .

Tato operace, která přenese celý snapshot, může chvíli trvat, hlavně když je zdrojový systém souborů velký. Je to také znatelně pomalejší než použití rsync nebo dvojice příkazů tar pro přenos do cílového systému souborů. Použití jednoho z těchto alternativních způsobů by mohlo fungovat, ale používání send/receive zajistí, že je vše připraveno tak, jak to tyto příkazy Btrfs očekávají.

Pozor na to, že když zdrojový snapshot není jen ke čtení, tak s ním btrfs send odmítne pracovat. Zdá se, že pro dodatečné nastavení příznaku jen ke čtení na existujícím snapshotu nemá btrfs žádný povel, ale pokud je to potřeba, pak je samozřejmě jednoduché udělat nový snapshot jen ke čtení ze zapisovatelného snapshotu.

Jakmile máme na cílovém systému souborů počáteční kopii, pak už jde přírůstkové zálohy dělat tak, že na zdrojovém systému souborů uděláme nový snapshot a pak spustíme příkaz:

cd záložní-systém-souborů
btrfs send -p cesta-k-předchozímu-snapshotu cesta-k-novému snapshotu | btrfs receive .

Díky příznaku -p odešle btrfs send jen soubory (nebo části souborů), které se změnily od vytvoření předchozího snapshotu; pozor na to, že předchozí snapshot musí na záložním systému souborů existovat také. Na rozdíl od počátečního kopírování jsou přírůstkové operace send vcelku rychlé – mnohem rychlejší než používání příkazu jako rsync k nalezení a odeslání změněných souborů. Proto se dá používat k implementaci nenáročného zálohovacího mechanismu, který může běžet mnohokrát denně.

K plnému využití této funkčnosti bude ale asi potřeba nějaké skriptování. Například není žádoucí nechávat si na zdrojovém systému souborů všechny snapshoty, hlavně pokud se místa nedostává. Ale je nezbytné nechat si každý snapshot do doby, než bude provedena následující přírůstková operace send; použití počátečního snapshotu by vedlo ke zbytečnému kopírování spousty dat. Dá se předpokládat, že časem vzniknou rozumně uživatelsky přívětivé nástroje použitelné pro automatizaci těchto úloh.

Povely přes ioctl()

Jako většina komplexních linuxových systémů souborů taktéž Btrfs podporuje řadu ioctl() specifických pro tento systém souborů. Tyto příkazy jsou zpravidla naprosto nedokumentované; člověk se musí pohrabat ve zdrojovém kódu (kde těch komentářů také mnoho není), aby je nalezl a pochopil, co dělají. Tento článek nenahrazuje řádnou dokumentaci, ale několik zajímavých povelů vám ukáže.

Většina příkazů specifických pro Btrfs provádí operace, které jsou přístupné přes nástroj btrfs. Proto tam najdeme příkazy pro správu podjednotek a snapshotů, zařízení apod. Ve většině případů je nástroj btrfs ideálním nástrojem pro provádění těchto příkazů, proto se o těchto bavit nebudeme. Za pozornost stojí, že několik těchto příkazů existuje v několika verzích; první verze neměla pole (typicky flags), které bylo doplněno v druhé verzi.

Struktury a konstanty pro všechny příkazy ioctl() na Btrfs najdeme v <linux/btrfs.h>; na některých distribucích může být potřeba nainstalovat si příslušný vývojový (-dev) balíček, abychom tento hlavičkový soubor měli.

• Klonování souborů. Copy-on-write mechanismus Btrfs je možné používat k vytváření kopií, které sdílejí příslušné úložiště dat souboru, ale přesto se chovají jako nezávislé soubory. Soubor, který je takto „naklonován“, se bude chovat jako pevný odkaz (hard link), dokud nebudou ani originál ani kopie změněny; jakmile dojde ke změně, mechanismus COW okopíruje upravené bloky, čímž dojde k odchýlení těchto souborů. Vytvoření klonu souboru je otázkou jednoduchého volání:

  status = ioctl(dest, BTRFS_IOC_CLONE, src);

  Kde dest a src označují dvojici souborů, nad kterými se má pracovat; dest musí být otevřené a oba soubory se musejí nacházet na stejném systému souborů Btrfs.

  Pro vytvoření klonu části souboru nejprve naplníme takovouto strukturu:

  struct btrfs_ioctl_clone_range_args {
  	__s64 src_fd;
  	__u64 src_offset, src_length;
  	__u64 dest_offset;
  };
  

  Strukturu pak předáme jako argument povelu BTRFS_IOC_CLONE_RANGE:

  status = ioctl(dest, BTRFS_IOC_CLONE_RANGE, &args);

  Stejně jako u BTRFS_IOC_CLONE se cílový soubor předává jako první argument ioctl().

  Všimněte si, že funkce klonování je dostupná i na aktuálních linuxových systémech skrze volbu --reflink příkazu cp.

• Explicitní flush. Stejně jako na jiných systémech souborů i Btrfs udělá flash nezapsaných dat při voláních fsync() nebo fdatasync(). Synchronizaci můžeme zahájit i explicitně pomocí:

  u64 transid;
  
  status = ioctl(fd, BTRFS_IOC_START_SYNC, &transid);
  

  Toto zahájí operaci flush na systému souborů, který obsahuje fd, ale nebude se čekat na dokončení. Volitelný argument transid bude nastaven na interní číslo transakce odpovídající požadované operaci flush. Pokud by bylo potřeba počkat na dokončení, můžeme tak učinit pomocí:

  status = ioctl(fd, BTRFS_IOC_WAIT_SYNC, &transid);

  transid zde musí pocházet z volání BTRFS_IOC_START_SYNC. Bez něj se bude čekat na dokončení libovolné aktuální transakce.

• Řízení transakcí. Operace flush může být použita aplikací, která si chce být jistá, že je jedna transakce dokončena, než začne dělat něco dalšího. Programátoři, kteří ale rádi žijí na hraně, mohou ovšem použít povely BTRFS_IOC_TRANS_START a BTRFS_IOC_TRANS_END (bez argumentů) k explicitnímu zahájení a ukončení transakcí na systému souborů. Všechny operace na systému souborů provedené mezi těmito voláními budou ostatním procesům viditelné atomicky; částečně provedené transakce vidět nebudou.

  Třebaže tato funkce vypadá užitečně, je nutné vzít v potaz komentář ze souboru fs/btrfs/ioctl.c:

  /*
   * existuje řada způsobů, jak mohou volání trans_start a trans_end vést
   * k deadlocku. Měly by být používány jen aplikacemi, kterým stroj v podstatě
   * patří a které opravdu do hloubky rozumí všem možným deadlockům a problémům
   * s enospc.
   */
  

  Většina vývojářů asi postrádá „porozumění do hloubky“ ohledně toho, co se na Btrfs může pokazit. Navíc není jak zrušit transakci; takže když aplikace zhavaruje vprostřed transakce, transakce bude dokončena jádrem a všechna práce udělaná před pádem bude vidět. Proto správnou odpovědí všem vývojářům, kteří zvažují využití této funkce, je téměř s jistotou „nedělejte to“. Kdokoliv, kdo se o to bude snažit, bude stejně muset mít právo CAP_SYS_ADMIN.

Btrfs obsahuje řadu dalších povelů ioctl() podporovaných na Btrfs, ale jak bylo zmíněno výše, většinu z nich je asi lepší použít přes nástroj btrfs. Zvědavci je mohou najít na konci souboru fs/btrfs/ioctl.c ve stromu jádra.

Závěr seriálu

Tímto je seriál o Btrfs u konce. Většina funkčnosti nabízené tímto systémem souborů byla v rámci celkem pěti článků popsána. Ačkoliv má několik vývojářů nápady na další zajímavé funkce, většina z nich se do hlavní řady jádra pravděpodobně brzy nedostane; namísto toho se teď vývoj upírá směrem ke stabilnímu a výkonnému systému souborů.

Jen málo znalých vývojářů je teď toho názoru, že je Btrfs připravené k produkčnímu nasazení, takže práce na stabilizaci a výkonu ještě nějakou dobu potrvají. Navzdory tomu čím dál více uživatelů Btrfs zkouší a i díky tomu je Btrfs více prověřené. I když je obtížné dělat podobné odhady, tak se dá říci, že za rok nebo dva by Btrfs mohl být přijímán jako systém souborů produkční kvality pro čím dál více situací.

       

Komentáře

[benghi]

Send/receive je úžasná věc, jelikož to podle mýho půjde vysypat na pásku, blicí disk či do fajlu. Zvlášť na pásce mi to společně s inkrementálním zálohováním připadá úžasný.

[luky]

Z toho popisu my vyplyva, ze klonovane soubory budou mit stejny inode, coz mi prijde nezadujici - pokud je napriklad zataruju a pak roztaruju, tak nedostanu 2 kopie, ale 2 hardlinkovane soubory.

[Filip Jirsák]

To by nemohlo fungovat, ne? Když pak jeden z klonů souboru změním, měly by dva různé soubory stejný inode - a to podle mne nejde. Podle mne klonování naopak znamená, že jsou dva inode, které ale do první změny sdílí stejné datové bloky.

[pavlix]

Já si hlavně myslím, že z toho textu nic takového nevyplývá.

[luky]

... Soubor, který je takto „naklonován“, se bude chovat jako pevný odkaz (hard link), dokud ...

[pavlix]

Chápu to tak, že právě to slovo dokud a co za ním následuje, jasně ukazuje na to, že nemůžou sdílet inode.

[Filip Jirsák]

Bude se chovat jako pevný odkaz, ne bude to pevný odkaz. Znamená to, že bude mít klíčové vlastnosti stejné, jako pevný odkaz - v tomto případě to, že se při vytvoření nic nekopíruje a kopie nezabírá žádné nové místo na disku.

[luky]

Bude se chovat jako pevný odkaz, ne bude to pevný odkaz. Znamená to, že bude mít klíčové vlastnosti stejné, jako pevný odkaz - v tomto případě to, že se při vytvoření nic nekopíruje a kopie nezabírá žádné nové místo na disku.

Prave ze ne, kopie musi spotrebovat jeden inode, jinak nastane ten problem, co jsem popsal.

[pavlix]

O tom se nikdo nepře ;).

[luky]

V tom pripade se to ale vubec nechova jako hardlink

[Filip Jirsák]

Taksi to zkuste. Naklonujte si na btrfs soubor, a uvidíte, že po klonování nebudete mít datové bloky souboru na disku dvakrát (jako u obyčejného kopírování), ale jednou (jako u hardlinku).

[pavlix]

A na vyjádření názoru, že sdílení datových bloků na disku nepovažuješ za dostatečnou podobnost s hardlinkem, jsi napsal už asi pět komentářů? Tomu říkám efektivní komunikace.

[luky]

No prave, IMO se novy inode musi naalokovat hned a ne az kdyz se soubor zmeni.

[ebik]

inode je pouze struktura obsahujici odkaz(y) na datove bloky. Inody budou mit ruzne. Datove bloky budou mit spolecne. Pokud do jednoho datoveho bloku jednoho souboru nekdo neco zapise, tak se predela ten odkaz na novy datovy blok a tam se zapise zmena. (Copy on write). Takze z pohledu OS jsou to ruzne soubory se vsim vsudy, pouze FS se stara o "kompresi" pomoci deduplikace dat. Chova se to pak podobne jako komprimovany FS: kdyz mas soubor velikosti 10MB a prepises ho jinymi daty o stejne velikosti, tak se zmeni velikost volneho mista (klidne muze najednou dojit).

[Honz]

Správné by bylo napast " s toho popysu my viplívá"...

[čavo]

Mám problém s pripájaním BTRFS, na ktorom sú data RAID1

# btrfs fi df /home/
Data, RAID1: total=268.84GiB, used=182.90GiB
System, RAID1: total=64.00MiB, used=48.00KiB
System, single: total=4.00MiB, used=0.00
Metadata, RAID1: total=18.00GiB, used=426.36MiB

# mount | grep home
/dev/sda2 on /home type btrfs (rw)

niekedy sa pripája tak cez mount /dev/sda2 a niekedy cez mount /dev/sdb2 a nikdy neviem dopredu po štarte, cez ktoré meno sa má pripájať (cez to druhé sa s chybou nepripojí). LABEL a UUID mi prideluje jadro po štarte náhodne ku jednému z nich a najčastejšie ku tomu, cez ktorý sa to nedá pripojiť.

Samozrejme podľa zákonu maslového chleba, to je tak, že zakaždým je to presne ten druhý ako napíšem do /etc/fstab (už som skúšal aj LABEL a UUID), ale podľa pozorovaní sa po reštarte automaticky pripojí len v asi 10% prípadov.

Nepoužívam initrd a vo stab som priebežne vyskúšal tieto možnosti:

#/dev/sda2              /home           btrfs           noatime,nodiratime,autodefrag,noacl     1 2
#/dev/sdb2              /home           btrfs           noatime,nodiratime,autodefrag,noacl     1 2
#LABEL=home             /home           btrfs           noatime,nodiratime,autodefrag,noacl     1 2
UUID=fba01cbb-f374-4815-a9da-0f98c27fee21       /home   btrfs   noatime,nodiratime,autodefrag,noacl     1 2
#/dev/sdb2              /home           btrfs           noatime,nodiratime,autodefrag,noacl,device=/dev/sda2,device=/dev/sdb2               1 2
#/dev/sda2              /home           btrfs           noatime,nodiratime,autodefrag,noacl,device=/dev/sda2,device=/dev/sdb2               1 2

Prakticky som vyskúšal všetky možné zápisy čo som našiel na internete. Len ten stroj nevypínam často a tak ma štve, keď po reštarte sa musím potom pomocou ssh pripojiť (špeciálne som si musel vytvorit používateľa mimo /home), ručne pripojiť disk s /home a poreštartovať služby, ktoré sú na prístupnosti /home závislé.

Poznáte niekto iný zázračný postup ako to vyriešiť? Je možné, že mám ten súborový systém zle vytvorený. Mätie ma hlavne položka „System, single: ...“

[čavo]

Ups. Zabudol som pripísať. Používam aktualizované Gentoo.

# uname -a
Linux octopus 3.10.25-gentoo #1 SMP Tue Feb 4 07:31:51 CET 2014 x86_64 AMD A8-5600K APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux

# equery l btrfs\*
 * Searching for btrfs* ...
[IP-] [  ] sys-fs/btrfs-progs-3.12-r1:0/0

[jas]

To, ze sa niekedy meni pismeno disku je normalne. Problem je, ze niekedy trva dlhsie jednemu disku kym sa inicializuje a inokedy druhemu. Presne na riesenie podobnych problemov vzniklo UUID, kedze to je celkom bezny problem. Problem moze byt napr. v tom, ze init system necaka dostatocne dlho, kym zacne pripajat disky.

Skuste porovnat casove znamky jadra (dmesg), kedy ukaze, ze sa spamatal jeden, kedy druhy disk, kedy su tam nejake hlasky o tom, ze sa pripaja disk a pod. Ak sa pozadovany disk spamata neskor, tak je problem skutocne v init systeme. Riesenie moze byt napr. napisat si init script, ktory caka kym jadro spostredkuje dany disk (cca len nieco ako "while test ! -f /dev/disk/by-uuid/$UUID;do sleep 0.1;done")

Alternativne by mohol byt problem s duplikovanymi UUID a pod. (predsa len, je to raid 1). Co vypisuje prikaz blkid? Co vypisuje jadro, ked pripajanie disku padne?

Este jedna vec, netusim ako presne sa riesi v linuxe hw raid (a drzim sa hesla: 'hw raid: nikdy' prave kvoli mnozstvu bugov, co su v ich firmwaroch a neriesia sa), ale nevytvari jadro nahodou aj /dev/mdX zariadenie, ktore sa da normalne pripojit?

[čavo]

Neviem či sa disky prečíslovávajú, ale klasický md v jadre problém nemá. (nemám tam nikde HW RAID a mám tam aj klasický RAID z jadra), tento RAID je z BTRFS (keďže je to článok o btrfs)

# mount | column -t
rootfs       on  /                      type  rootfs    (rw)
/dev/md0     on  /                      type  jfs       (rw,noatime)
devtmpfs     on  /dev                   type  devtmpfs  (rw,relatime,size=7890724k,nr_inodes=1972681,mode=755)
proc         on  /proc                  type  proc      (rw,relatime)
tmpfs        on  /run                   type  tmpfs     (rw,nosuid,nodev,relatime,size=1578228k,mode=755)
devpts       on  /dev/pts               type  devpts    (rw,nosuid,noexec,relatime,gid=5,mode=620)
shm          on  /dev/shm               type  tmpfs     (rw,nosuid,nodev,noexec,relatime)
sysfs        on  /sys                   type  sysfs     (rw,nosuid,nodev,noexec,relatime)
debugfs      on  /sys/kernel/debug      type  debugfs   (rw,nosuid,nodev,noexec,relatime)
cgroup_root  on  /sys/fs/cgroup         type  tmpfs     (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
openrc       on  /sys/fs/cgroup/openrc  type  cgroup    (rw,nosuid,nodev,noexec,relatime,release_agent=/lib64/rc/sh/cgroup-release-agent.sh,name=openrc)
cpu          on  /sys/fs/cgroup/cpu     type  cgroup    (rw,nosuid,nodev,noexec,relatime,cpu)
/dev/md1     on  /mnt/portage           type  ext4      (rw,noatime)
/dev/sda2    on  /home                  type  btrfs     (rw)

Čiže sú dva samostané disky (partície) /dev/sda2 a /dev/sdb2, pomocou btrfs prepojené do RAID1. Akurát, že btrfs nevytvára nový názov RAID-ovaného poľa a tak sa to pripája pomocou mena jedného z diskov. Problém je, že nemôžem použiť, ktorékoľvek meno z tých diskov, ale určité konkrétne a ešte ďalší problém je, že nedokážem predikovať, ktoré s tých mien mám použiť, pretože sa nezastupujú, ale cez to druhé sa to pripojiť nedá. UUID a LABEL (majú oba disky nastavené, predpokladám), ale „zväčša“ je to v jadre pridelené práve tomu, cez ktorý sa mi to nedarí pripojiť.

[jas]

UUID a label neprideluje jadro, su zapisane na disku (sucast hlaviciek file systemu). UUID je nahodne generovane user-space aplikaciou (v tomto pripade mkfs.btrfs) zatial co LABEL nastavuje uzivatel (neviem aky prikaz je na to pri btrfs, nepouzivam btrfs).

Kazdopadne pozeral som navody ako vlastne ten raid v btrfs funguje a moj typ je jednoduchy: jeden disk obsahuje len naklonovane metadata a ziadne data (alebo naopak, len data), zatial co druhy obsahuje oboje a preto aj ide pripojit.

Vystup prikazov 'blkid' (pod rootom, inak nezobrazi detaily o systemovych particiach, ale len uzivatelovych -- tj. zvacsa nic) a 'btrfs filesystem show' by v tomto pomohol omnoho viac nez vypis mount.

Pouzilo sa pri vytvarani mkfs.btrfs -m raid1 -d raid1 /dev/<1st> /dev/<2nd> alebo sa -m ci -d zabudlo?

[ebik]

Asi mas rozbity neco v konfiguraci toho raidu. Sice btrfs nerozumim, ale RAID1 by snad mel jit pripojit pres oba disky, jinak je ti na houby. (Kdyz ti odejde do vecnych lovist ten disk, pres ktery to mountis, jak se dostanes na ten druhy?)

[čavo]

To je to, že asi, pretože ani po nabehnutí systému sa to neda pripojiť cez ktorýkoľvek disk, ako to je písane v návodoch. Lenže som neprišiel na to, čo som zle vygeneroval. tento disk si teraz nemôžem len tak zrušiť a skúšať na ňom, tak to asi bude ešte skúšať na iných diskoch a uvidím, či ta to bude rovnako správať.