Dotaz: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila

[LarryL]

Zdravím. Snažím se o deduplikaci dat na HDD (cca 3,5TB dat) jehož mountpoint je /mnt/btr_archive. Na HDD jsou snapshoty btrfs nakopírované pomocí btrfs send/receive. Jinými slovy je tam mnoho btrfs subvolumes jen pro čtení.

V těchto několika různých subvolumes jsou stejné soubory, které jsou poměrně velké. Moje představa byla, že na celý HDD spustím deduplikaci pomocí nástroje duperemove a že to udělá následující:

- najde duplicitní soubory,

- ponechá data pouze jednoho z duplicitních souborů,

- u ostatních duplicitních nastaví reflink (podobně jako pri cp --reflink=always) a data duplicit smaže,

- a tím se uvolní místo na HDD.

Použil jsem příkaz:

sudo duperemove -dr /mnt/btr_archive --hashfile=/mnt/btr_archive/Duperemove/duperemove_archive.hashfile

Už to jede asi 10 dnů a zatím se žádné místo neuvolnilo. Hashfile už zabírá 11 GB. Ze začátku HDD byl slyšet permanentně jak načítá data, teď už jen občas. V termínálu to vypisuje něco jako:

0x55b96b1268e0] Dedupe for file "/mnt/btr_archive/Duperemove/duperemove_archive.hashfile" had status (1) "data changed".
[0x55b96b1269a0] (5/5) Try to dedupe extents with id a78ec70c
[0x55b96b1269a0] Dedupe 49 extents (id: a78ec70c) with target: (131072, 131072), <jméno souboru>

a pak to stojí třeba hodinu, HDD nic nedělá, ale proces duperemove vytěžuje CPU na 25%.

Mám to nechat běžet dál a čekat, že za pár dnů to skončí a uvolní místo na HDD nebo to mám stopnout a zkusit jinak?

Odpovědi

[pet I.]

a pak to stojí třeba hodinu, HDD nic nedělá, ale proces duperemove vytěžuje CPU na 25%.

Řekl bych, že máš jedno jádro ze čtyř vytíženo na 100%.

Doporučil bych raději bees, verzi 0.11.

[LarryL]

Díky za odpověď. Máš pravdu jedno jádro vytěžuje vždy na 100%.

Jestli to chápu správně tak duperemove je souborová deduplikace a bees bloková. Je pro BTRFS v něčem lepší duperemove nebo je vždy lepší bees? Když zkusím bees, máš nějaký odhad jak dlouho to bude trvat pro 3,5 TB dat (dny, týdny)?

[Peter Golis]

Nie je tu nejaký evangelizátor BTRFS?

[Want]

Je. A má být?

[Want]

Je bambilion způsobů jak vytvořit subvolume. A deduplikace nemusí fungovat vždy podle tvých představ.

Já to řešil tak, že jsem měl lokální Btrfs ale ty snapshoty jsem rsyncoval na sdílený disk - pak to vyrábělo jen rozdíly.

[Andrej]

Je bambilion způsobů jak vytvořit subvolume.

Já tedy vím o ± dvou a půl (subvolume create / subvolume snapshot / receive). Zbytek z toho bambilionu mi asi nějak unikl. (Stárnu, příliš chlastám, atd.)

Já to řešil tak, že jsem měl lokální Btrfs ale ty snapshoty jsem rsyncoval na sdílený disk - pak to vyrábělo jen rozdíly.

Huh? Odkdy rsync vyrábí jen rozdíly? Má sice volbu --inplace, která je velmi žádoucí, ale v žádném případě nemůže nahradit „hlubší povědomí“ :-P o snapshotech.

• U drobných změn v existujících souborech sice --inplace pomáhá, ale vůbec neřeší efektivní přejmenování / přesun souborů / adresářů. V takových případech rsync brutálně duplikuje. Rozdílové snapshoty na Btrfs se duplikaci vyhnou.
• Nemluvě o cp --reflink: rsync umí zachovat pouze hardlinky na úrovni celých souborů, zatímco o cp --reflink na úrovni bloků nemá ponětí → hurá, zase všechno zduplikovat!

Zachování (pouze) rozdílů při synchronizaci mezi zdrojovým Btrfs se snapshoty a cílovým Btrfs s kopiemi příslušných snapshotů lze docílit například (a možná jedině) pomocí btrfs send -p ... | btrfs receive ... (Hlavně nezapomenout na -p…)

[LarryL]

Andreji, ty používáš na deduplikaci bees, jak již bylo v diskuzi doporučeno, nebo deduplikaci vůbec neřešíš?

[Andrej]

Neřeším.

Ne že by včely nebyly super, ale nemám pro ně momentálně nasazení, protože moje data nemají příliš mnoho duplicit.

Spíš se snažím existující ne-duplicity (snapshoty, cp --reflink atd.) zachovat a nezduplikovat omylem. To mi prozatím vždy stačilo (== nezabralo povážlivě moc místa).

Mám jednoduchý zálohovací skript, který (0) sejme snapshot na zdroji, (1) přenese snapshot na cíl (efektivně, pouze rozdíly) a (2) „exponenciálně“ naředí minulé snasphoty, aby byly směrem do minulosti postupně stále řidší. (Je-li zdroj malý a cíl velký, pro úsporu místa stačí držet na zdroji jenom jeden minulý snapshot a víc snapshotů si zachovávat jen na cíli. Aby efektivní diffy fungovaly (na obou stranách), stačí jen ten jeden snapshot.)

[LarryL]

OK, zastavil jsem duperemove a zkusím bees.

[LarryL]

rsyncoval na sdílený disk - pak to vyrábělo jen rozdíly.

Ty máš zřejmě na mysli rozdíly přírůstkových snapshotů. Já ale potřebuji zdeduplikovat různé větve snapshotů ve kterých jsou shodné soubory. V tom mi rsync ani send/receive nepomůže. Navíc bych považoval za krok zpátky používat rsync místo send/receive.

[Want]

To byla ještě jiná doba, kdy byla maximální kapacita fyzického disku 1TB. Snapshotovaly se domovské adresáře v rámci nodu, kde ten virtuál běžel. A ten rsync jsem použil, když jsem to pak potřeboval sesypat na jeden disk, jako extra zálohu. Dnes už to nepoužívám, protože jsou uživatelské adresáře sdílené z Netappu.

[pet I.]

Já mám 2 TB disk plný sekvenčně dělaných snapshotů přenášených pomocí send/receive a když jsem zkusil duperemove tak mi končilo na nedostatku paměti. Použil jsem bees a ušetřilo mi to dalších cca 15 % místa.

[LarryL]

U duperemove jsem problém s nedostatkem paměti neměl. Teď zkouším bees, pak napíšu jak to dopadlo.