Názory k článku
Btrfs v jádře 5.20 bude používat send/receive v2

Teď jenom tajně doufám, že tam zůstane zpětná kompatibilita... Aby se mi nestala nehezká ošklivá věc, že až zupdatuju kernel na workstationě v době, kdy na serveru ještě 5.20 nějakou dobu jako stable nebude, tak budu bez zálohování :-)

Nebojíš se že je send/receive příliš lowlevel operace, která by mohla případnou corruption na FS propsat i do zálohy tak nešťastně, že přestanou fungovat i předchozí snapshoty?

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.

A problém by jako měl být v čem?

Že mu bleeding edge klient pošle deltu ve formátu v2 a konzervativní server ji nebude umět rozbalit a vysypat do live kopie zálohovanýho systému.

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 :-)