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 13:22 | Komunita

    Vývoj linuxové distribuce Clear Linux (Wikipedie) vyvíjené společností Intel a optimalizováné pro jejich procesory byl oficiálně ukončen.

    Ladislav Hagara | Komentářů: 1
    včera 14:00 | Zajímavý článek

    Byl publikován aktuální přehled vývoje renderovacího jádra webového prohlížeče Servo (Wikipedie).

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

    V programovacím jazyce Go naprogramovaná webová aplikace pro spolupráci na zdrojových kódech pomocí gitu Forgejo byla vydána ve verzi 12.0 (Mastodon). Forgejo je fork Gitei.

    Ladislav Hagara | Komentářů: 0
    17.7. 18:44 | Zajímavý článek

    Nová čísla časopisů od nakladatelství Raspberry Pi zdarma ke čtení: Raspberry Pi Official Magazine 155 (pdf) a Hello World 27 (pdf).

    Ladislav Hagara | Komentářů: 1
    17.7. 16:11 | Nová verze

    Hyprland, tj. kompozitor pro Wayland zaměřený na dláždění okny a zároveň grafické efekty, byl vydán ve verzi 0.50.0. Podrobný přehled novinek na GitHubu.

    Ladislav Hagara | Komentářů: 4
    17.7. 15:55 | Komunita

    Patrick Volkerding oznámil před dvaatřiceti lety vydání Slackware Linuxu 1.00. Slackware Linux byl tenkrát k dispozici na 3,5 palcových disketách. Základní systém byl na 13 disketách. Kdo chtěl grafiku, potřeboval dalších 11 disket. Slackware Linux 1.00 byl postaven na Linuxu .99pl11 Alpha, libc 4.4.1, g++ 2.4.5 a XFree86 1.3.

    Ladislav Hagara | Komentářů: 5
    16.7. 21:22 | IT novinky

    Ministerstvo pro místní rozvoj (MMR) jako první orgán státní správy v Česku spustilo takzvaný „bug bounty“ program pro odhalování bezpečnostních rizik a zranitelných míst ve svých informačních systémech. Za nalezení kritické zranitelnosti nabízí veřejnosti odměnu 1000 eur, v případě vysoké závažnosti je to 500 eur. Program se inspiruje přístupy běžnými v komerčním sektoru nebo ve veřejné sféře v zahraničí.

    Ladislav Hagara | Komentářů: 19
    16.7. 16:22 | IT novinky

    Vláda dne 16. července 2025 schválila návrh nového jednotného vizuálního stylu státní správy. Vytvořilo jej na základě veřejné soutěže studio Najbrt. Náklady na přípravu návrhu a metodiky činily tři miliony korun. Modernizovaný dvouocasý lev vychází z malého státního znaku. Vizuální styl doprovází originální písmo Czechia Sans.

    Ladislav Hagara | Komentářů: 26
    16.7. 15:33 | Upozornění

    Vyhledávač DuckDuckGo je podle webu DownDetector od 2:15 SELČ nedostupný. Opět fungovat začal na několik minut zhruba v 15:15. Další služby nesouvisející přímo s vyhledáváním, jako mapyAI asistent jsou dostupné. Pro některé dotazy během výpadku stále funguje zobrazování například textu z Wikipedie.

    bindiff | Komentářů: 8
    16.7. 13:33 | Bezpečnostní upozornění

    Více než 600 aplikací postavených na PHP frameworku Laravel je zranitelných vůči vzdálenému spuštění libovolného kódu. Útočníci mohou zneužít veřejně uniklé konfigurační klíče APP_KEY (např. z GitHubu). Z více než 260 000 APP_KEY získaných z GitHubu bylo ověřeno, že přes 600 aplikací je zranitelných. Zhruba 63 % úniků pochází z .env souborů, které často obsahují i další citlivé údaje (např. přístupové údaje k databázím nebo cloudovým službám).

    Ladislav Hagara | Komentářů: 6
    Kolik tabů máte standardně otevřeno ve web prohlížeči?
     (25%)
     (25%)
     (13%)
     (0%)
     (0%)
     (0%)
     (0%)
     (38%)
    Celkem 8 hlasů
     Komentářů: 3, poslední dnes 17:26
    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: 994×
    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.
    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?
    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.