V souborovém systému BTRFS se send a receive používá pro jednoduchou synchronizaci změn mezi dvěma subvolumes. Do jádra 5.20 byly v pondělí poslány záplaty pro stream v2. Nově bude možné posílat přímo komprimovaná data, bez nutnosti dekomprese a opětné komprese.
Aby vše fungovalo, bude potřeba také nové btrfs-progs. Zatím ve verzi 5.18.1 ze 6. června stream v2 ještě nejsou.
(zdroj: phoronix)
Send/receive je naopak velmi high level, je to proud libc-like operací. Open, seek, write, rename, unlink... a nemá to jak ovlivnit předchozí snapshot (z principu kravských filesystemů - nelze modifikovat, jen přidávat nové záznamy, takže starý blok na který ukazují reference ze starých snapshotů zůstane bez změn).
On se především nemá čeho bát, leda snad šiřietlů mýtů a strachu z neznámého.
Zaprvé, který jiný FS by tady byl vzorem pro srovnání? Který jiný FS chrání proti poškození dat, nejen metadat? Že by snad fosilie bez checksumů, u které se poškození dat dostane klidně i do čtení ze souborů přes rsync? To asi ne, což…?
Zadruhé, jak přesně by se ta poškozená (meta)data (u kterých by neseděl checksum) měla dostat do send / receive streamu? Zázrakem? Chybou v Matrixu? Nějaké jiné návrhy?
Zatřetí, jak by na základě “následujícího” přeneseného snapshotu mohly přestat fungovat předchozí snapshoty (dejme tomu, že read-only)? Asi také zázrakem? Nebo je snad send / receive formát tak špatně navržený, že může vnést do cílového filesystému blíže neurčenou zkázu? :-D Bug report k tomu je kde? V reálu to funguje tak, že nekompletní přenos snapshotu má stejný výsledek, jako by žádný snapshot nepřibyl a žádný přenos neproběhl. Nekompletní přenos snapshotu nastane právě třeba v případě, kdy se uprostřed vytváření send / receive streamu zjistí, že některý kousek (meta)dat nelze přečíst (protože nesedí checksum) a tedy přenést. Což je chyba, proti které (například) zastaralý FS + rsync nechrání vůbec, zatímco btrfs send / receive s ní umí předvídatelně pracovat.
Začtvrté, send / receive je *jediný* postup, který správně zachovává (fakt) všechny atributy ve filesystému, nejen POSIX ACL, extended attributes, řídkost souborů (i stolice) atd. atp., ale třeba i pseudo-deduplikaci vycházející z "cp --reflink". U neatomického povrchního zálohování pomocí rsync se musí používat šílenosti typu "rsync -acHAXS --delete", aby se aspoň částečně cosi zachovalo, ale jak už bylo řečeno, neřeší to hned několik zásadních věcí: (1) vzájemnou atomicitu souborů (a když už bych rsync volal na atomickém snapshotu, proč radši nepoužít rovnou send / receive?), (2) atributy specifické pro filesystém / OS a případně jiné atributy přidané v budoucnu, které "-HAXS" nezahrnuje, (3) soubory zkopírované (částečně) pomocí "cp --reflink", které rsync nemá jak správně ošetřit (protože API, se kterým pracuje, mu tuhle informaci nedává) a tudíž je (s)prostě zduplikuje. U send / receive žádný z těchto problémů neexistuje.
Nevím jak to mají doprasené v Synology, ale z jejich btrfs nejde send/receive na btrfs z normálního Linuxu, protože tam mají nějakou změnu měnící formát filesystému. btrfs receive prostě skončí na "unsupported type".
Tak teď v téhle chvíli jsem rád, že když se mi rozsypal poslední nas a naznal jsem, že bude jednodušší postavit druhý vedle, než to na současných datech opravovat, tak jsem nakonec vzal microserver a nacpal na to vlastní OS, než se snažit rozchodit synology a zálohovat btrfs na něj... což jak vidím... by zas nefungovalo :-)
