abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 06:00 | Komunita

    Na čem aktuálně pracují vývojáři GNOME a KDE Plasma? Pravidelný přehled novinek v Týden v GNOME a Týden v KDE Plasma. Vypíchnout lze, že v Plasmě byl implementován 22letý požadavek. Historie schránky nově umožňuje ohvězdičkovat vybrané položky a mít k ním trvalý a snadný přístup.

    Ladislav Hagara | Komentářů: 0
    včera 20:00 | Nová verze

    Wayfire, kompozitní správce oken běžící nad Waylandem a využívající wlroots, byl vydán ve verzi 0.10.0. Zdrojové kódy jsou k dispozici na GitHubu. Videoukázky na YouTube.

    Ladislav Hagara | Komentářů: 0
    včera 04:00 | Komunita

    Před necelými čtyřmi měsíci byl Steven Deobald jmenován novým výkonným ředitelem GNOME Foundation. Včera skončil, protože "nebyl pro tuto roli v tento čas ten pravý".

    Ladislav Hagara | Komentářů: 7
    29.8. 18:33 | Zajímavý článek

    Nové číslo časopisu Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 156 (pdf).

    Ladislav Hagara | Komentářů: 0
    29.8. 15:11 | Nová verze

    Armbian, tj. linuxová distribuce založená na Debianu a Ubuntu optimalizovaná pro jednodeskové počítače na platformě ARM a RISC-V, ke stažení ale také pro Intel a AMD, byl vydán ve verzi 25.8.1. Přehled novinek v Changelogu.

    Ladislav Hagara | Komentářů: 0
    29.8. 12:11 | IT novinky

    Včera večer měl na YouTube premiéru dokumentární film Python: The Documentary | An origin story.

    Ladislav Hagara | Komentářů: 0
    28.8. 23:33 | Nová verze

    Společnost comma.ai po třech letech od vydání verze 0.9 vydala novou verzi 0.10 open source pokročilého asistenčního systému pro řidiče openpilot (Wikipedie). Zdrojové kódy jsou k dispozici na GitHubu.

    Ladislav Hagara | Komentářů: 0
    28.8. 21:55 | Nová verze Ladislav Hagara | Komentářů: 4
    28.8. 14:11 | IT novinky

    Řada vestavěných počítačových desek a vývojových platforem NVIDIA Jetson se rozrostla o NVIDIA Jetson Thor. Ve srovnání se svým předchůdcem NVIDIA Jetson Orin nabízí 7,5krát vyšší výpočetní výkon umělé inteligence a 3,5krát vyšší energetickou účinnost. Softwarový stack NVIDIA JetPack 7 je založen na Ubuntu 24.04 LTS.

    Ladislav Hagara | Komentářů: 4
    28.8. 00:44 | Bezpečnostní upozornění

    Národní úřad pro kybernetickou a informační bezpečnost (NÚKIB) spolu s NSA a dalšími americkými úřady upozorňuje (en) na čínského aktéra Salt Typhoon, který kompromituje sítě po celém světě.

    Ladislav Hagara | Komentářů: 26
    Pro otevření více webových stránek ve webovém prohlížečí používám
     (80%)
     (9%)
     (3%)
     (4%)
     (4%)
     (1%)
    Celkem 114 hlasů
     Komentářů: 9, poslední 28.8. 11:53
    Rozcestník

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

    3.7. 22:28 LarryL | skóre: 27
    Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Přečteno: 2123×
    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?

    Řešení dotazu:


    Odpovědi

    4.7. 10:26 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    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.
    4.7. 13:51 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    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)?
    4.7. 22:20 Peter Golis | skóre: 65 | blog: Bežné záležitosti | Bratislava
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Nie je tu nejaký evangelizátor BTRFS?
    4.7. 23:14 Want
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila

    Je. A má být?

    4.7. 23:20 Want
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila

    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.

    5.7. 09:54 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    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…)

    5.7. 10:29 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Andreji, ty používáš na deduplikaci bees, jak již bylo v diskuzi doporučeno, nebo deduplikaci vůbec neřešíš?
    5.7. 10:52 Andrej | skóre: 51 | blog: Republic of Mordor
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila

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

    5.7. 16:11 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    OK, zastavil jsem duperemove a zkusím bees.
    5.7. 10:27 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    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.
    5.7. 15:21 Want
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila

    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.

    7.7. 11:47 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    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.
    8.7. 00:42 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    U duperemove jsem problém s nedostatkem paměti neměl. Teď zkouším bees, pak napíšu jak to dopadlo.
    11.7. 16:37 gut
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Kdyby sis treba nejdriv zjistil, jak btrfs NEfunguje, nemusel bys vymejslet cypoviny ....

    Snap JE JEN ROZDIL. Vzdy. Tudiz ho jaksi deduplikovat nelze, protoze neni co. To ze tam vidis stejny obrovsky soubory je jaksi vlastnost. Na disku to jsou identicky bloky.

    Dale, zadna souborova deduplikace na brtfs NEEXISTUJE. Duperemove nic nededuplikuje. Precte vsechny souborama obsazeny bloky na disku, spocita z nich hashe, ty pak porovna a pokud najde identicky, preda IDcka tech bloku btrfs a to provede deduplikaci.

    A kupodivu, nez se spocitaji hashe na celym disku tak to trva. A pochopitelne je to prudce ovlivnovano i tim, jestli se ta databaze hashu vejde nebo nevejde do ram. duperemove si poradi i bez ty ramky, ale pak ty hashe prohledava na disku, coz je neprekvapive radove pomalejsi.

    Pochopitelne si muzes poradne nadelat do vlastniho, pokud tu databazi ukladas na stejnej disk, kterej se snazis deduplikovat. Coz zcela zjevne delas ...

    A vrchol debility je, poustet ten dedup pres snapy, coz zcela zjevne delas taky.

    Takze to ze ti to pobezi mesicE, je zcela vporadku, muzes si za to sam. Protoze ten disk se ti celej bude cist tolikrat, kolik snapu tam mas.

    On totiz neprekvapive duperemove nevi, ze cte dokola totez. A presne proto mas taky 11GB velkej ten hash file ...

    hasfile 6TB dat ma cca 2,5GB.

    A pochop[itelne ti to zadny misto neuvolni, protoze viz vejs.

    11.7. 16:50 Stevo | skóre: 9
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Ďakujem. Chcel som to isté napísať, ale si vravím, že to nemá význam, kým sa chlapec nenaučí, alebo aspoň netuší ako to funguje na nižších vrstvách. Často sa učíme na vlastných chybách a keď hľadáme riešenia, tak sa učíme. Dúfam že sa aj dotyčný niečo naučil. Ja som sa tiež musel naučiť a kopu vecí doteraz neviem....
    11.7. 19:15 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Snap JE JEN ROZDIL. Vzdy. Tudiz ho jaksi deduplikovat nelze
    To vím :-) Stejné soubory jsou v RŮZNÝCH větvích snapshotů. Někde jsem to tu psal. Zkusím to vysvětlit detailněji: Na disku jsou snapshoty z několika různých počítačů. Různé počítače mají některé soubory stejné. Proto se ve výsledku tyto stejné soubory dostanou na jeden HDD (ten co se snažím dedupliovat), ale soubory nemají spolu žádnou spojitost.
    zadna souborova deduplikace na brtfs NEEXISTUJE
    Proč to mají v dokumentaci rozdělené na souborovou a blokovou deduplikaci?
    tu databazi ukladas na stejnej disk, kterej se snazis deduplikovat. Coz zcela zjevne delas
    To možná nebylo nejmoudřejší, ale to asi nebyla příčina toho, že duperemove ve druhé fázi na disk vůbec nešahal. Používal převážně CPU (jedno jádro), něco počítal.
    A vrchol debility je, poustet ten dedup pres snapy, coz zcela zjevne delas taky.
    Stejné soubory v RŮZNÝCH větvích snapshotů jsem vysvětlil v 1. bodu. Nebo něčemu vadí, že snapshoty jsou read-only?
    Takze to ze ti to pobezi mesicE, je zcela vporadku, muzes si za to sam.
    Už 5 dnů běží bees a pořád šahá na HDD. Ale deduplikuje jen přes den. Kdyby jel měsíce tak bych byl zklamaný. :-(
    Protoze ten disk se ti celej bude cist tolikrat, kolik snapu tam mas. On totiz neprekvapive duperemove nevi, ze cte dokola totez.
    Pokud je to pravda tak je duperemove pěkně na prd. Předpokládám, že u bees takový problém není když je dělaný pro BTRFS.
    11.7. 19:22 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    U 3. odpovědi mělo být místo "duperemove ve druhé fázi na disk vůbec nešahal" správně "duperemove ve druhé fázi na disk SKORO vůbec nešahal".
    Řešení 1× (Stevo)
    17.7. 08:51 gut
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    "Na disku jsou snapshoty z několika různých počítačů. Různé počítače mají některé soubory stejné"

    === porad si nepochopil zaklady.
    /mount/btrfs 
    
    /mount/btrfs/base/pc1
    /mount/btrfs/base/pc2
    /mount/btrfs/base/pc3
    ...
    Tohle deduplikovat muzes
    
    mount/btrfs/snaps/pc1
    mount/btrfs/snaps/pc2
    mount/btrfs/snaps/pc3
    ...
    Tohle deduplikovat je hovadina
    
    Pekne naprd to neni, krumpac taky predpokalda ze krumpacista vi jak se snim dela.
    17.7. 14:35 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Mám to takto:
    mount/btrfs/DIR-PC1/snaps_date_time
    mount/btrfs/DIR-PC2/snaps_date_time
    mount/btrfs/DIR-PC3/snaps_date_time
    ...
    Soubory v snaps_date_time v různých DIR-PCx o sobě neví. Jsou na sobě nezávislé. Deduplikace by měla ušetřit místo. Pokud myslíš, že ne, napiš důvod.

    PS: bees stále běží. Když jsem ho asi před 2 dny přerušil tak jsem si všiml, že zatím žádné volné místo nepřibylo. Stal se opak, volného místa ubylo asi 150 GB. Možná je to nějaký odpad, který na disku vznikl při deduplikaci a BTRFS ho ještě nezahodil.
    21.7. 10:39 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Soubory v snaps_date_time v různých DIR-PCx o sobě neví. Jsou na sobě nezávislé. Deduplikace by měla ušetřit místo.
    Ano, přesně tak to funguje a bees od v0.11 v těchto případech ani neprocházejí data opakovaně (jako duperemove).
    PS: bees stále běží. Když jsem ho asi před 2 dny přerušil tak jsem si všiml, že zatím žádné volné místo nepřibylo. Stal se opak, volného místa ubylo asi 150 GB. Možná je to nějaký odpad, který na disku vznikl při deduplikaci a BTRFS ho ještě nezahodil.
    Ono bývá vhodné si přečíst dokumentaci výrobce, to je ty chytrosti co jsou na stránce dole (včetně odkazů). Tam se mimo jiné píše, že při spuštění bees na disku, kde ještě neběžely, to ze začátku nějaké místo zabere a až pak se projení uvolňování a je tam i vysvětleno proč.
    21.7. 13:49 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Ano, přesně tak to funguje a bees od v0.11 v těchto případech ani neprocházejí data opakovaně (jako duperemove).
    Nainstaloval jsem bees v0.10, který jsem měl v repozitáři. Bees jede už možná stejně dlouho jako před tím duperemove, ale zatímco duperemove pak už téměř nešahal na HDD tak bees šahá permanentně.

    Volné místo se zatím neuvolnilo. Dám tomu ještě pár dnů, pak to zastavím a počkám na v0.11.

    Vadí mi, že není možnost nastavit, aby deduplikoval jen bloky u větších souborů (>5 MB). Tím by se to mohlo hodně urychlit a zároveň to uvolní nejvíce volného místa.
    21.7. 15:57 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Volné místo se zatím neuvolnilo. Dám tomu ještě pár dnů, pak to zastavím a počkám na v0.11.

    Vadí mi, že není možnost nastavit, aby deduplikoval jen bloky u větších souborů (>5 MB). Tím by se to mohlo hodně urychlit a zároveň to uvolní nejvíce volného místa.
    No práve bees má od verze v0.11 zásadně přepracovaný přístup ke skenování. Zatímco do v0.10 včetně skenovaly podobně jako duperemove po souborech (a prováděly opakované čtení), od verze v0.11 skenují přímo po extentech a při deduplikaci upřednostňují velké extenty. Dnes jsem spustil deduplikaci na 12 TB disku plném snapshotů různých OS (čekal jsem až bude v0.11 vydaná jeko stabilní) a slibuje mi:
    PROGRESS:
    extsz   datasz  point gen_min gen_max this cycle start tm_left   next cycle ETA
    ----- -------- ------ ------- ------- ---------------- ------- ----------------
      max   6.298T 050663       0  535350 2025-07-21 11:25   3d 9h 2025-07-25 01:42
      32M   2.338T 024682       0  535350 2025-07-21 11:25   1w 4h 2025-07-28 20:31
       8M 728.658G 007716       0  535350 2025-07-21 11:25   3w 2d 2025-08-14 01:55
       2M 232.671G 002777       0  535350 2025-07-21 11:25   9w 2d 2025-09-25 01:14
     512K  87.983G 001503       0  535350 2025-07-21 11:25  17w 1d 2025-11-19 13:03
     128K  58.983G 000004       0  535350 2025-07-21 11:25       -                -
    total   9.719T        gen_now  535804                  updated 2025-07-21 15:47
    
    že cca do týdne budou velké rozsahy deduplikovány. A že pak ty malá pojedou ještě půl roku mi už nevadí.

    Předchozí deduplikaci na 2 TB disku jsem dělal v0.11_rc3 s vynikajícími výsledky.

    Doporučuji pokus s v0.10 skončit a začít znovu s v0.11.
    21.7. 17:18 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Ten výpis časů jsi získal pomocí parametru "--scan-mode"? Jak dlouho scanování trvá?

    Chápu správně, že do týdne budeš mít deduplikované rozsahy >=32MB, ale deduplikace pojede dál, pokud ji nezastavíš, a rozsahy >=512 KB budou hotové až za 17 týdnů? To jsem nevěděl, že to trvá tak dlouho.
    21.7. 19:30 Peter Golis | skóre: 65 | blog: Bežné záležitosti | Bratislava
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Sú technológie kde to trvá kratšie, alebo je to dokonca vykonávané za jazdy. Ale vybral si si BTRFS.
    21.7. 21:29 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    U kterých technologií to trvá kratěji? Nebuďte slušny, řekněte jméno.

    Za jízdy? Tím myslíš, že při každém zápisu souboru se obsah porovná se zbytkem souborů na disku a ihned se deduplikuje? To by musely být pekelně pomalé zápisy na disk.

    S BTRFS zatím spokojenost, nehodlám měnit.
    21.7. 21:49 Peter Golis | skóre: 65 | blog: Bežné záležitosti | Bratislava
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    U kterých technologií to trvá kratěji? Nebuďte slušny, řekněte jméno.
    Napr. u ZFS a iných riešení. A to vrátane hotových komerčných diskových polí ktoré si to riešia v rámci vlastnej réžie, a plne transparentne.
    Tím myslíš, že při každém zápisu souboru se obsah porovná se zbytkem souborů na disku a ihned se deduplikuje?
    Nie. Pri každom zápise sa vytvorí kontrolný súčet bloku, ktorý sa porovná s už existujúcou a zindexovanou tabuľkou. A ak nie je unikátny, tak sa namiesto zápisu len zreferencuje.
    S BTRFS zatím spokojenost, nehodlám měnit.
    Závisí na prioritách ktoré sú určené potrebnou funkcionalitou.

    PS: Dúfam že máš ECC RAM.
    22.7. 10:06 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Pri každom zápise sa vytvorí kontrolný súčet bloku, ktorý sa porovná s už existujúcou a zindexovanou tabuľkou.
    Jo, tak jsem to myslel. Při každém zápisu na disk se musí zároveň porovnávat s hash tabulkou celého disku (poolu). Deduplikace bude podobně náročná všude, z dokumentace ZFS:

    The deduplication process is very demanding! There are four main costs to using deduplication: large amounts of RAM, requiring fast SSDs, CPU resources, and a general performance reduction. The trade-off with deduplication is reduced server RAM/CPU/SSD performance and loss of top-end I/O speeds in exchange for saving storage size and pool expenditures.

    Deduplikace jako vestavěná součást ZFS mě nepřesvědčí, abych přešel z BTRFS na ZFS.
    22.7. 18:03 Peter Golis | skóre: 65 | blog: Bežné záležitosti | Bratislava
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Jo, tak jsem to myslel. Při každém zápisu na disk se musí zároveň porovnávat s hash tabulkou celého disku (poolu).
    Tá tabuľka kontrolných súčtov je v RAM, takže bu ma zaujímalo aký dosah na výkon to môže mať. Teda ak si človek nepostaví NAS na nejakom Atome. Pri deduplikácii je viac ako odporúčané používať stroj v záruke, a s ECC RAM. Také majú výkonu viac ako dosť.

    Teda ak tam človek nenapchá niekoľko kusov 40G sieťoviek ktoré vyťaží.
    10.8. 23:25 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Ono jak se to vezme "very demanding". Připadá mi, že ti jde primárně o deduplikaci backupu. Uděláš snap, a zazálohuješ. Z různých systémů na jeden server. A pouze čistými prostředky btrfs. Pokud to tak je, a fakticky ti nejde o deduplikaci živých dat, tak zauvažuj o zálohovacím systému. Já více než 10 let používám backuppc. Deduplikce je integrální součásti záloh. Server má soubory uložené v stromu podle hash hodnoty souboru a soubory v DIR-PC1/date_time jsou hard linky na ty hashe. Má modifikované rsync a pokud klient na PC narazí na soubor, který má zálohovat, spočte hash, a pokud je na serveru soubor s tímto hashem, tak se ani nepřenáší a jen server vytvoří hard link. Duplikace je okamžitá, přirozená a už při vzniku souboru. Navíc je možné zvolit i kompresi zálohy, což sice už má menší význam, protože mnoho formátů má lepší kompresi než obecné LZW, ale je to tam. Tak zauvažuj jestli to má smysl.
    11.8. 16:54 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Díky za tip. Ano jde o deduplikaci backupu, přesněji zatím to zkouším na archivu (záloha zálohy).
    backuppc ... pokud klient na PC narazí na soubor, který má zálohovat, spočte hash, a pokud je na serveru soubor s tímto hashem, tak se ani nepřenáší a jen server vytvoří hard link. Duplikace je okamžitá, přirozená a už při vzniku souboru
    To zní dobře. Nyní řeším zálohování BTRFS systémů. Proto na zálohování používám Btrbk, který je určen především na zálohování BTRFS systémů. Na zálohovaném stroji si udělá snapshot a ten pomocí btrfs send/receive přesune na stroj se zálohami. Pro BTRFS mi to přijde jako čistější atomické zálohování než rsync, který zřejmě používá BackupPC.

    Trochu mám u BackupPC obavu, že když se deduplikace (porovnávání hashů) provádí hned při procesu zálohování, že bude zálohování o to déle trvat, oproti zálohování pomocí btrfs send/receive. Nyní čekám až se mi v repozitáři objeví bees 0.11, bo se mi to nechce kompilovat ručně, a pak budu zkoušet dál a napíšu jak to dopadlo.
    15.8. 09:33 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Jen pro info:

    Je to 11 TiB disk, byl plný z 90% přibližně podobnými daty jako máš ty. Navíc je to i systémový dist toho serveru.

    Bees jsem spustil 21.07.2025. Cca za týden bylo obsazeno jen cca 50%. Přihrál jsem další data a na nich okamžitě proběhla deduplikace na větších blocích.

    Dnes to vypadá takto:

    PROGRESS:
    extsz   datasz  point gen_min gen_max this cycle start tm_left   next cycle ETA
    ----- -------- ------ ------- ------- ---------------- ------- ----------------
      max   4.212T   idle  616339  616340 2025-08-15 09:16       -                -
      32M 514.804G   idle  616339  616340 2025-08-15 09:16       -                -
       8M 221.872G   idle  616339  616340 2025-08-15 09:16       -                -
       2M   69.08G   idle  616339  616340 2025-08-15 09:16       -                -
     512K  64.688G 059424  616339  616340 2025-08-15 09:16 10m 17s 2025-08-15 09:27
     128K   8.953G 893350       0  535350 2025-07-21 11:25  2d 23h 2025-08-18 08:40
    total    5.07T        gen_now  616341                  updated 2025-08-15 09:17
    
    Obsazeno je 47%, na všech větších blocích proběhlo už několik průběhů, jen bloky do 128K jsou před koncem prvního průchodu.
    16.8. 13:27 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Jo. Tak nějak bych si to představoval.
    17.8. 01:34 lertimir | skóre: 64 | blog: Par_slov
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila

    Nabizim zobrazení jak zobrazuje mé (na chalupě běžící) BackupPC zálohy (konkrétně to je manželčin notebook)

    to kam běží záloha je RPi4 s diskem na USB  na 100Mbit lince a notebook je na wifi

     

    Tyhle rychlosti jsou jen díky hash a dedupliikaci.

     

     

    Manželka už roky o ničem neví a jen má zapnutý notebook dost často.

     

     

     

    File Size/Count Reuse Summary

    Existing files are those already in the pool; new files are those added to the pool. Empty files and SMB errors aren't counted in the reuse and new counts.

    Totals Existing Files New Files
    Backup# Type #Files Size/MiB MiB/sec #Files Size/MiB #Files Size/MiB
    1135 incr 869317 137690.9 85.58 66 102.0 16329 1476.0
    1134 incr 863770 137958.9 87.43 27 0.6 17541 1434.2
    1133 incr 859815 137970.4 87.60 267 23.4 6556 1946.2
    1132 full 872104 137669.4 31.83 7 0.0 13023 1157.1
    1131 incr 867496 137683.3 81.86 67 24.1 23029 1486.5
    1130 incr 868807 137668.3 96.07 21 20.2 10627 1311.7

     

    Ty odkazy samozřejmě nevedou nikam.

    22.7. 08:59 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Ten výpis časů jsi získal pomocí parametru "--scan-mode"? Jak dlouho scanování trvá?
    Ten výpis je z konce status souboru (cat /run/bees/ca1ccace-4aef-4cf7-8d66-f438b53f5d6b.status, spuštěno přes beesd). Teď to vypadá takto:
    PROGRESS:
    extsz   datasz  point gen_min gen_max this cycle start tm_left   next cycle ETA
    ----- -------- ------ ------- ------- ---------------- ------- ----------------
      max   7.987T 236516       0  535350 2025-07-21 11:25  2d 20h 2025-07-25 04:41
      32M   1.029T 132784       0  535350 2025-07-21 11:25  5d 17h 2025-07-28 02:24
       8M 424.109G 054617       0  535350 2025-07-21 11:25   2w 1d 2025-08-06 13:57
       2M  152.04G 020778       0  535350 2025-07-21 11:25   5w 6d 2025-09-01 19:28
     512K  77.386G 006418       0  535350 2025-07-21 11:25  19w 3d 2025-12-05 11:26
     128K  51.152G 000038       0  535350 2025-07-21 11:25       -                -
    total   9.705T        gen_now  537574                  updated 2025-07-22 08:32
    
    Ty časy jsou průběžné odhady a dost se mění, hlavně u těch malých extentů co mají nízkou prioritu.
    Chápu správně, že do týdne budeš mít deduplikované rozsahy >=32MB, ale deduplikace pojede dál, pokud ji nezastavíš, a rozsahy >=512 KB budou hotové až za 17 týdnů? To jsem nevěděl, že to trvá tak dlouho.
    Jo, deduplikace už pojede pořád, a až na ten disk něco připíšu (je tam systém i veškerá data) tak se to zdeduplikuje hned. Momentálně je to cca 10 TB obsazenosti disku, du by našlo odhadem několik set TB snad možná i dokonce celý PB.

    Za těch cca 21 hodin to uvolnilo cca 6 TB.
    22.7. 09:27 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Za těch cca 21 hodin to uvolnilo cca 6 TB.
    Sorry, oprava:

    Za těch cca 21 hodin to uvolnilo cca 0,6 TB.

    22.7. 10:36 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Dík za info. U v0.10 v souboru *.status ten výpis na konci nemám takže předpokládám, že ho přidali až v v0.11.
    a až na ten disk něco připíšu (je tam systém i veškerá data) tak se to zdeduplikuje hned
    Jak se dívám do dokumentace bees tak tam píší, že problém je když se nejdříve vytvoří snapshoty a pak se na ně spustí bees (můj případ). To zřejmě vyřešili ve verzi 0.11. Když se nejdříve spustí bees a pak se přidávají snapshoty tak problém by být neměl a deduplikace nových snapshotů probíhá rychle.

    Jak jsem psal, že kvůli deduplikaci ubylo cca 150GB volného místa (možná to bylo méně), z dokumentace jsem pochopil, že jsou to nová medatada co bees vytvořil kvůli procházení jednotlivých snapshotů, tak teď přemýšlím jestli nenakopírovat všechna data na disk znovu a nezačít s deduplikací s v0.11 od začátku, abych se těch zbytečných metadat zbavil.
    22.7. 13:10 pet I. | skóre: 13
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Tak od minulého příspěvku se mi uvolnilo dalších 0,2 TB.

    Co se týká mazání a nového vytváření, tak já bych se tím nezdržoval. Prostě bych na to pustil bees v0.11 a až bude (dostatečně) hotovo, tak bych na to pustil btrfs balance, pro jistotu se zastavenými bees.
    16.7. 09:15 Martin
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Snap JE JEN ROZDIL. Vzdy. Tudiz ho jaksi deduplikovat nelze, protoze neni co. To ze tam vidis stejny obrovsky soubory je jaksi vlastnost. Na disku to jsou identicky bloky.
    Snap deduplikovat ide. Pretoze ten "rozdiel" môže byť rôzny. Napr. ak si si spustíš napr. defragmentáciu, tak ti rozdiel medzi aktuálnymi dátami a snapshotom bude rásť bez toho aby sa zmenil jediný bit v tvojich dátach. A v najhoršom prípade budeš mať dáta veľkosti xyGB a snapshot tiež xyGB. Deduplikácou sa môžes priblížiť znova k ideálnemu stavu, kedy je rozdiel medzi dátami a snapshotom minimálny možný.

    K pôvodnej otázke ešte taký postreh. Je lepšie si pustiť deduplikáciu nie na celý disk ale po menších kúskoch. Ak máš na disku napr. video, faktury, fotky, mp3 tak pusti dedup na /mnt/disk/video + /mnt/disk/snapshot/video, potom na "/mnt/disk/mp3 + /mnt/disk/snapshot/mp3" a tak ďalej. Jednoducho, keď je možné predpokladať, že takmer žiadane duplicity medziadresárovo neexistujú. Je s tým viacej roboty, ale proces skončí rýchlejšie. Postup po menších kúskoch je dobrý aj na testovanie, keď nečakáš týždeň na výsledok aby si zistil, že si použil nesprávny switch alebo čo a žiadne miesto si neušetril.
    Řešení 1× (Stevo)
    17.7. 08:42 gut
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Vetsi hovadinu jsem necet uz opravdu dlouho ... placas paty pres devaty, zjevne vubec nemas paru o tom, jak jsou organizovany data na libovolny FS, natoz na btrfs.

    !!de(fragmentace) data naprosto nijak nemeni.!! a na btrfs muze neco takovyho delat leda opravdovy blb, ktery nevi co pouziva.

    Btrfs totiz fragmentuje data z definice svy existence s kazdym jednim zapisem. To sprosty slovo ktery neznas se jmenuje COW.
    17.7. 11:14 Martin
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Možno si len nepochopil. Nikde nepíšem, že by defragmentácia menila dáta. Ale mení "veľkosť rozdielu". Neviem ako to napísať lepšie, tak sem dám citáciu z dokumentácie https://btrfs.readthedocs.io/en/latest/Defragmentation.html
    Warning

    Defragmentation does not preserve extent sharing, e.g. files created by cp --reflink or existing on multiple snapshots. Due to that the data space consumption may increase.
    A mimochodom sú aj iné operácie pri ktorých sa rozbije extent sharing. Koniec koncov keby deduplkácia nemala zmysel, tak by nikto nepísal nástroj na deduplikáciu, že?
    Btrfs totiz fragmentuje data z definice svy existence s kazdym jednim zapisem.
    No a čo?
    15.8. 08:18 gut
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Zase placas paty pres devaty a motas dohromady deduplikaci a defragmentaci coz jsou naprosto nesouvisejici veci ze?
    16.8. 13:37 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Nemotá deduplikaci a defragmentaci. Snaží se ti vysvětlit, že např. defragmentace může přerušit vazbu sdílených dat mezi jednotlivými snapshoty nebo mezi sdílenými daty vytvořenými pomocí cp --reflink.

    Rozporuješ toto tvrzení?
    20.8. 17:34 gut
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Takze tomu taky nerozumis ...

    DE(fragmentace) nedela NIC jinyho, nez se soupe datovy bloky po disku a snazi se je srovnat zasebe tak, aby cteni bylo linearni. To na BTRFS nelze NIKDY docilit. Nijak nezasahuje do organizace dat.

    DE(duplikace) prozmenu nijak nehyba s daty na disku, meni pouze organizaci dat = zasahuje do metadat. Nic jinyho nedela.

    Snapshoty jsou zcela mimo tema, nebot je nelze ani defragmentovat ani deduplikovat, jedno i druhe je velepicovina na nich delat. Zcela zbytecny osoupavani disku.

    Na BTRFS lze nekteryma operacema zrusit (uplne nebo castecne) deduplikaci. Napriklad tim, ze se provede kopie souboru ze? Zazracna vec.

    Proto je potreba deduplikaci spoustet pravidelne, protoze i v pripade, ze se na disku jen hybe s daty ktera tam jsou, tak v zavislosti na tom kterou dirou se tam leze vznikaji duplicity (samba to mimochodem umi bez toho, kdyz se spravne nastavi).

    21.8. 01:33 LarryL | skóre: 27
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    Proč píšeš o datech a metadatech? Řeč je přece o Logical Address Space kde si BTRFS uchovává odkazy na fyzické bloky.
    Na BTRFS lze nekteryma operacema zrusit (uplne nebo castecne) deduplikaci. Napriklad tim, ze se provede kopie souboru ze? Zazracna vec.
    Kopie souboru se provádí i při defragmentaci.

    Mám dojem, že někdo z nás dvou se v diskuzi ztratil a píše o něčem úplně jiném :-)
    17.7. 23:32 Stevo | skóre: 9
    Rozbalit Rozbalit vše Re: Deduplikace na BTRFS pomocí duperemove trvá dlouho a místo neuvolnila
    https://www.youtube.com/watch?v=3JnOCMDPeBE

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.