Hlavní navigace

Btrfs v jádře 5.20 bude používat send/receive v2

22. 7. 2022

Sdílet

Disky Autor: Depositphotos

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)

Našli jste v článku chybu?
  • Aktualita je stará, nové názory již nelze přidávat.
  • 22. 7. 2022 12:49

    SPM

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

  • 22. 7. 2022 18:42

    Jan Hrach
    Stříbrný podporovatel

    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?

  • 22. 7. 2022 20:32

    Jakub Štech

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

  • 25. 7. 2022 1:44

    Shewlin

    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.

  • 23. 7. 2022 20:05

    Jakub Štech

    Ž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.

  • 24. 7. 2022 11:20

    Vantomas
    Stříbrný podporovatel

    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".

  • 27. 7. 2022 11:02

    SPM

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

Byl pro vás článek přínosný?

Autor zprávičky

První linux nainstaloval kolem roku 1994 a u něj zůstal. Později vystudoval fyziku a získal doktorát.