Názor k článku
Btrfs v jádře 5.20 bude používat send/receive v2 od Shewlin - On se především nemá čeho bát, leda snad...

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.