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 02:00 | Pozvánky

Konference OpenAlt 2018 (dříve LinuxAlt a Openmobility) proběhne již o víkendu 3. a 4. listopadu na FIT VUT v Brně. Motto konference je "Otevřeným přístupem k otevřené společnosti". Připraveno je 8 tracků přednášek a workshopů. Pořadatelé připravili výběr toho nejzajímavějšího.

Ladislav Hagara | Komentářů: 0
včera 01:00 | IT novinky

Bylo vydáno RFC 8484 řešící posílání DNS dotazů a získávání DNS odpovědí přes protokol HTTPS (DoH, DNS over HTTPS). V aktuálních verzích Firefoxu je DoH ve výchozím nastavení zakázáno. Povolit jej lze v about:config změnou hodnoty network.trr.mode (Trusted Recursive Resolver). V srpnu zveřejnila Mozilla výsledky experimentu s DNS přes HTTPS ve Firefoxu Nightly.

Ladislav Hagara | Komentářů: 27
19.10. 13:00 | Komunita

Při prvním spuštění Ubuntu 18.04 LTS (Bionic Beaver) je spuštěn nástroj Ubuntu Report. Pokud uživatel souhlasí, jsou pomocí tohoto nástroje odeslány do Canonicalu informace o daném počítači (doba instalace, počet procesorů, rozlišení displeje, velikost paměti, časová zóna, ...). V červnu byly zveřejněny první statistiky. Podrobnější statistiky jsou nově k dispozici na samostatné stránce.

Ladislav Hagara | Komentářů: 12
19.10. 01:00 | Pozvánky

O víkendu probíhá v Košicích pravidelné setkání příznivců otevřených technologií OSS Víkend. Na programu je řada zajímavých přednášek a workshopů.

Ladislav Hagara | Komentářů: 0
19.10. 00:11 | Nová verze

Byla vydána nová verze 1.3 otevřeného, licenčními poplatky nezatíženého, univerzálního ztrátového formátu komprese zvuku Opus (Wikipedie) a jeho referenční implementace libopus. Vylepšena byla například detekce, zda se jedná o řeč nebo o hudbu. Přidána byla podpora prostorového zvuku (immersive audio) dle plánovaného RFC 8486. Podrobnosti a zvukové ukázky na demo stránce.

Ladislav Hagara | Komentářů: 0
18.10. 22:33 | Nová verze

Bylo vydáno Ubuntu 18.10 s kódovým názvem Cosmic Cuttlefish (Kosmická sépie). Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 3
18.10. 18:33 | Nová verze

Byl vydán PostgreSQL ve verzi 11.0. Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
18.10. 17:33 | IT novinky

Nadace Raspberry Pi představila na svém blogu Raspberry Pi TV HAT, tj. rozšíření jednodeskového počítače Raspberry Pi umožňující příjem televizního vysílání DVB-T a DVB-T2. Cena rozšíření je 21,50 $.

Ladislav Hagara | Komentářů: 9
18.10. 17:07 | Nová verze

Vychází OpenBSD 6.4. Z řady novinek namátkou: podpora dalších architektur (arm64 např. dostal z Linuxu vypůjčený ovladač radeondrm), hypervizor vmm podporuje i qcow2 disky a šablony, jádro dokáže automaticky přepínat mezi dostupnými bezdrátovými sítěmi, sítě pracují o něco efektivněji, z bezpečnosti „přísaha byla doplněna odhalením“ (pledge(2) lze vhodně doplnit pomocí unveil(2)), SMT je ve výchozím stavu vypnutý, ale lze jej zapnout. Syntaxe nastaveni OpenSMTPD se změnila. S vydáním vychází také nová verze LibreSSL - 2.8.2.

Daniel Čižinský | Komentářů: 5
17.10. 23:15 | IT novinky

Firma Raptor Computing Systems, která stojí také za pracovní stanicí Talos II, představila levnější desku Blackbird s podporou jednoho 4-/8jádrového CPU POWER9 Sforza a formátem microATX; bližší specifikace jsou ve wiki výrobce.

Fluttershy, yay! | Komentářů: 30
Přispíváte osobně k vývoji svobodného softwaru?
 (39%)
 (43%)
 (25%)
 (22%)
 (11%)
 (36%)
Celkem 274 hlasů
 Komentářů: 16, poslední dnes 03:42
Rozcestník

rmlint - řešení duplicit

22.3.2017 09:05 | Přečteno: 1503× | Za vším hledej Linux | Výběrový blog | poslední úprava: 22.3.2017 09:05

Znám velmi málo lidí schopných udržet pořádek v uložených souborech a mají můj obdiv. Většina lidí to vzdá a situaci kdy začne zápolit s nedostatkem místa vyřeší tím, že si pořídí větší disk. Jenže takové řešení – obzvláště těm, kterým na datech záleží ­– leze do peněz. Žádná kapacita disku není nekonečná, protože místo zabírají nejenom nově přibývající soubory, ale také soubory zduplikované. Nejběžnější formou zálohy – obzvláště u těch co neznají git – je prostá kopie souboru. A když pak dochází místo řeší situaci tím, že obvykle zmáznou starší zálohy. Ovšem je dost lidí, co jsou schopni bez většího přemýšlení a nostalgie smáznout i data která jim později chybí.

Vzhledem k tomu, že jsem v dávné minulosti několikrát o data přišel, přistupuji k čištění disku velice obezřetně. A protože disková kapacita mého notebooku je poměrně omezená (jak vysvětlím o něco níže), ukládal jsem svoje data na externí média. Ale poté co jsem se vypekl s Blue-Ray mechanikou, jsem dospěl k závěru, že tato forma záloh je o ničem.

Relativně spolehlivé CD má mimo nedostatečné kapacity především tu nevýhodu, že s vypáleným souborem již nelze dále pracovat. Je tak vhodné pro pasivní zálohu, ale rozhodně se nehodí ke skladování velkého archívu dokumentů (elektronické dokumenty, videa, audio), který je třeba průběžně třídit.

Proto jsem před 5 lety soustředil veškerá svá data na centrálním domácím úložišti. S tím, že data postupně přeberu a přírůstek nových dat bude kompenzován průběžným odstraňováním duplicitních souborů. Ale skutek utek a záhy jsem to vzdal. Místa je zatím poměrně dost, tak jsem to dál neřešil.

Mnohem palčivější byl problém s místem na notebooku. Stroj, co mi běží jako centrální úložiště není trvale v provozu, protože zároveň funguje jako pracovní stanice a kvalita mobilního připojení v ČR také není žádná sláva. Proto mám data se kterými průběžně pracuji uložená na notebooku. Na úložišti mám archivní soubory s nimiž běžně nepracuji (audio a video) a odsypané zálohy.

Ovšem i tak čas od času mi na notebooku dojde místo. Co si tedy počít, pokud chci mít k dispozici všechna data, ale nemám čas na to abych v nich udělal pořádek a kapacitu blokového zařízení nelze za rozumný peníz zvětšit?

Toť ožehavá otázka, při které záleží na tom, na jaký souborový systém jste vsadili. Pokud jste vsadili – jako já – na Btrfs, pak máte šanci získat nějaké volné místo, aniž byste museli investovat do koupě nového hardwaru a odmazat některá svá data.

Rekomprese extentů

Defragmentace a rekomprese extentů je prvním krokem, který nic nestojí. S kompresí Btrfs pracuje od jádra verze 2.6.38, ovšem o tom, kdy ji použije na datový obsah extentu rozhoduje výkon vašeho procesoru. Je-li výkon CPU dostatečný a systém stíhá extenty komprimovat v reálném čase, je to v pohodě. Ovšem pokud nestíhá, tak se data ukládají bez komprese. Pochopitelně máte možnosti si ji vynutit, ovšem v případě souborů, které již nějakým způsobem komprimovány jsou, to může být kontraproduktivní – kupř. při skladování videozáznamů, komprimovaných archívů, či obrázků. Jenom se tím ještě více připravíte o výkon CPU.

Mnohem lepší je do výchozího nastavení Btrfs nešťourat a dodatečnou rekompresi využít právě v situaci, že je potřeba uvolnit nějaké místo. Bohužel to má háček – není možné předem zjistit kolik místa se tímto způsobem podaří uvolnit. Jinak je to jednoduché:

root@stroj~# btrfs filesystem defrag -v -r -czlib -l 32768 /

Vyždímal jsem takto z cca 200GB dat další 3GB volného místa.

Diskový prostor na mém notebooku

Protože SSD diskům nevěřím, používám od r. 2013 Btrfs v raid1 nad dvěma SSD disky. Původně to bylo 2x60GB – schválně jsem zvolil menší kapacitu, protože čím víc místa je k dispozici, tím víc blbostí si člověk uloží.

Soubory s videem jako potenciální rezerva

Místo neřeším obvykle do okamžiku, kdy dojde. Pro tento případ mívám na disku uložené tak dva tři filmy. Když je dlouhá cesta, je co pustit klukovi a pokud dojde místo, je to nejrychlejší cesta k tomu, jak nějaké získat.

Nevím kdo z vás zažil zaplácnuté Btrfs, každopádně nejde o nic tragického, jak se kdosi v nedávné diskuzi domníval. Důležité je vědět že Btrfs z principu nikdy nedovolí zaplácnout úplně celý disk.

Co u mne zabírá místo

Nejvíc místa u mne zabírají tyto věci:

Git repozitáře mi v současné době zabírají zhruba 11GB, protože je skladuji s celou historií. Jejich počet průběžně narůstal (s tím, jak vývojáři postupně přecházeli na GIT), takže mi zhruba po roce přestalo 60GB stačit. Navíc původní SSD z r.2012 měly tu nepěknou vlastnost že lagovaly, takže jsem je v lednu 2014 nahradil za 2x120GB SATA III Samsung 840 EVO.

Další upgrade diskového prostoru na úrovni hardware, jsem udělal v létě 2015, kdy jsem místo dvou SATA disků použil duální mSATA řadič s 2x250 GB mSATA Samsung 850 EVO. Což mi umožnilo vrátit do notebookového boxu zpět DVD mechaniku.

Jak jsem narazil na rmlint

Naposledy mi došlo místo minulý týden v pátek. To už jsem měl jednu větší čistku zhruba před půl rokem za sebou. Ovšem když jsem se podíval na kolik by vyšlo zakoupení 2x500GB mSATA, tak jsem si řekl, že to raději zkusím něco jiného. Předchozí aktualizace na úrovni hardware totiž vyšly pokaždé asi na polovinu a investovat 10 tisíc do pět let starého notebooku – který stejně bude nutné koncem roku vyměnit – nemá smysl.

Proto jsem udělal obvyklou čistku s rekompresí extentů a při tom mne napadlo, kouknout se jakpak asi vypadá u Btrfs aktuální situace s deduplikací. A na stránce wiki k Btrfs o deduplikaci jsem narazil na rmlint. Vzhledem k tomu, že je v oficiálním repozitáři Debianu, jsem nelenil, doinstaloval a vyzkoušel.

Co dělá rmlint?

Sám o sobě dělá jen to, že projíždí přehozený adresář, počítá kontrolní součty a hledá duplicitní soubory. Z nich pak jeden použije jako originál (soubor pro který byl shodný kontrolní součet vypočten nejdříve) a s ostatními jsou pro něj duplikáty. Na závěr zobrazí resumé, ze kterého je ihned jasné, jestli má vůbec smysl přistoupit k deduplikaci, nebo ne.

Kromě toho vygeneruje dva soubory: shellový skript rmlint.sh a soubor rmlint.json, ve kterém jsou všechny informace o nalezených duplicitních souborech. Pokud se rozhodnete, že opravdu chcete soubory deduplikovat, stačí spustit vygenerovaný skript rmlint.sh. Podstatná je tedy informace, že k realizaci změn dojde teprve po spuštění vygenerovaného skriptu rmlint.sh. Předtím se do něj můžete podívat a zkontrolovat jestli skript bude skript skutečně dělat to chcete.

Co obsahuje vygenerovaný skript?

Především obsahuje funkce, které se budou průběžně volat, nápovědu a pak seznam souborů k "opracování".

Deduplikace

Duplicitní soubory se nejčastěji objeví tak, že se jeden a týž soubor kopíruje z jednoho místa na druhé, a sem tam se i uloží pod jiným jménem.

Pokud rmlint najde takto zduplikovaný soubor, nabízí několik možností, jak situaci vyřešit. Záleží na tom, jaký používáte souborový systém a čeho tím vlastně chcete dosáhnout. U souborových systémů, které nepodpodporují deduplikaci můžete použít náhradní řešení: hardlink, nebo symlink. Jde však o řešení záludné, které se v určitých případech může hodit, ale tam, kde má jít o zálohy to může vést k fatálním důsledkům, pokud někdo do takového souboru hrábne.

Ideálním místem k otestování utility rmlint u mne byly prefixy pro PlayOnLinux, které zabíraly 18GB místa. Tyto prefixy totiž většinou obsahují kromě Win aplikací také nejrůznější systémové knihovny, které ještě nejsou implementované do wine. Spustil jsem tedy následující příkaz:

user@stroj:~$ rmlint -T df --config=sh:handler=clone .PlayOnLinux/wineprefix/
…
==> Note: Please use the saved script below for removal, not the above output.
==> In total 42941 files, whereof 14048 are duplicates in 4355 groups.
==> This equals 3,34 GB of duplicates which could be removed.

Wrote a sh file to: /home/user/rmlint.sh
Wrote a json file to: /home/user/rmlint.json
user@stroj:~$ ./rmlint.sh

Poté, co doběhnul vygenerovaný skript. jsem zkontroloval, zda-li skutečně došlo k uvolnění místa. A opravdu – po deduplikaci souborů v adresáři pro PlayOnLinux se uvolnilo dalších 2,5GB.

Použít clone, symlink, reflink nebo hardlink?

Klíčovou roli v tom co nakonec bude dělat vygenerovaný rmlint.sh, hraje zvolený handler. Deduplikace na úrovni souborového systému, která je relativně bez rizika, se udělá pouze v případě, že se použije volba clone nebo reflink. Než se dostanu k tomu, jaký je mezi nimi rozdíl, uvedu v čem se liší reflink (referenční odkaz) od hardlinku (pevný odkaz) a symlinku (symbolický odkaz).

Pevný odkaz - hardlink

U souborových systémů, které neznají reflink, lze řešit problém duplikovaných souborů přes pevné odkazy – hardlinky. Pro lepší představu: jméno souboru v rámci souborového systému, představuje katalogový lístek, který odkazuje na určité místo v souborovém systému – v případě Btrfs jde o metadata, která udržují informaci o datových extentech, které obsahují data souboru. Pevný odkaz (hardlink) je jiný lístek, s jiným jménem, v jiném místě katalogu, který ale odkazuje na stejná metadata a tím i na stejnou sadu datových extentů. Je tedy úplně jedno, jestli do obsahu hrábneme přes jeden, nebo druhý lístek katalogu – výsledek bude v obou případech stejný!

To pochopitelně nemusí vadit v situaci, kdy chceme aby byl jeden a ten samý soubor sdílený z více míst souborového systému. Ovšem v případě duplicitních souborů v zálohách, může mít použití hardlinku fatální důsledky, pokud nejsou tyto soubory přístupné pouze pro čtení.

Symbolický odkaz - symlink

Pevné odkazy (hardlinky) však mají omezení v tom, že se dají použít pouze v rámci jednoho souborového systému. Tam, kde byla adresářová struktura rozložená přes více datových zdrojů (sdílený síťový disk, externí disk, aj.) se místo pevného odkazu používá symbolický odkaz – symlink.

V tomto případě však nejde o katalogový lístek v rámci souborového systému (jako je jméno souboru), ale o speciální soubor, který obsahuje pouze informaci o tom kde se nalézá cíl. Není to tedy odkaz na metadata (jako hardlink), ale na jiný katalogový lístek.

Problém symlinků spočívá v tom, že (na rozdíl od hardlinků) existují v určitém kontextu, který se může změnit – stačí nabindovat adresář do jiného přípojného bodu, nebo se přepnout do chrootu a cesta k cílovému souboru přestane být platná.

Referenční odkaz - reflink

Funguje podobně jako pevný odkaz - hardlink. Také jde o katalogový lístek v rámci souborového systému, který se však od hardlinku liší tím, že má svá vlastní metadata, která však odkazují na stejné datové extenty. V okamžiku, kdy dojde k editaci souboru vytvořeného jako referenční link, zůstane původní sada datových extentů tak jak je a změny se uloží jako nový transparentní datový extent.

Metadata původního souboru, a původní sada extentů zůstane beze změny. Pouze v metadatech "odštípnutého" souboru přibude odkaz na další datový extent. V konečném důsledku všechy datové extenty pro oba soubory zaberou míň místa, než kdybychom vytvořili a upravili plnotučnou kopii souboru.

Poznámka: Na rozdíl od symlinku a hardlinku, vypadá reflink v rámci souborového systému jako zcela nezávislý soubor. Viz následující ukázkový příklad:

user@stroj:~$ touch soubor.txt
user@stroj:~$ cp --link soubor.txt soubor_link.txt
user@stroj:~$ cp --reflink soubor.txt soubor_reflink.txt
user@stroj:~$ cp --symbolic-link soubor.txt soubor_symlink.txt
user@stroj:~$ ls -ali soubor*.txt
22890902 -rw-r--r-- 2 want want  0 bře 17 16:28 soubor_link.txt
22890904 -rw-r--r-- 1 want want  0 bře 17 16:26 soubor_reflink.txt
22890907 lrwxrwxrwx 1 want want 10 bře 17 16:27 soubor_symlink.txt -> soubor.txt
22890902 -rw-r--r-- 2 want want  0 bře 17 16:28 soubor.txt
user@stroj:~$ echo obsah >> soubor.txt
user@stroj:~$ ls -ali soubor*.txt
22890902 -rw-r--r-- 2 want want  6 bře 17 16:28 soubor_link.txt
22890904 -rw-r--r-- 1 want want  0 bře 17 16:26 soubor_reflink.txt
22890907 lrwxrwxrwx 1 want want 10 bře 17 16:27 soubor_symlink.txt -> soubor.txt
22890902 -rw-r--r-- 2 want want  6 bře 17 16:28 soubor.txt

Zápisem do souboru soubor.txt byl dotčen pouze soubor_link.txt, který byl vytvořený jako hardlink. Že jde o hardlink na původní soubor.txt lze poznat jednak podle čísla 2 (které udává počet referencí na soubor), ale především podle stejného čísla inodu (22890902). Po zapsání dat do odkazovaného souboru, došlo k jeho "odštípnutí" a rozšíření metadatové sady extentů o nový extent, zatím co původní sada extentů, na kterou odkazují metadata pro soubor_reflink.txt zůstala beze změny.

Symlink soubor_symlink.txt lze identifikovat jednak podle písmena 'l', kterým začínají jeho atributy, ale i podle toho, že je při podrobném výpisu uveden cílový soubor na který odkazuje. Také je z výpisu patrné, že měl po vytvoření nenulovou velikost (protože jde o soubor s datovým obsahem), přestože odkazoval na soubor, který žádný obsah neměl.

Rozdíl mezi clone a reflink

Rozdíl mezi clone a reflink je pouze v tom, jakým způsobem rmlint nahradí duplicitní soubor.

Při clone, volá skript rmlint.sh binární soubor rmlint (přes který byl vygenerován), který na základě předaných parametrů nahradí v metadatech duplicitního souboru původní sadu datových extentů sadou extentů originálního souboru, uvolněné extenty odstraní ale číslo inodu zůstane beze změny.

Při reflinku, se duplicitní soubor nejprve odstraní (včetně metadat) a pak se znovu vytvoří přes cp, jako reflink na originál. Zde tedy platí co jsem zmínil výše – aby mohl být duplicitní soubor odstraněn, musí být k dispozici dostatek místa. A také to sebou může nést i nějaké další vedlejší účinky, protože se změní i číslo inodu.

Klíčový předpoklad pro deduplikaci

Po deduplikaci bodou existovat datové extenty deduplikovaných souborů vždy pouze v jednom exempláři. Je tedy bezpodmínečně nutné udělat maximum pro to, aby nedošlo k jejich poškození.

Protože žádnému fyzickému médiu nelze důvěřovat na 100%, je podle mne bezpodmínečně nutné, aby měl souborový systém datové extenty rozložené přinejmenším na dvě fyzická zařízení, aby v případě, že dojde k poškození jednoho z nich stále byla k dispozici nepoškozená kopie. Jestli se o to postará samo Btrfs (raid1) nebo jestli bude nad nějakým raid polem (pochopitelně vyšším než 0) je už vcelku jedno.

V každém jiném případě zcela reálně hrozí, při chybě na blokovém zařízení, že dojde ke ztrátě dat a nevratnému poškození souborového systému.

Post Scriptum

Jak zjistit, které hardlinky mají stejný cíl?

user@stroj:~$ sudo find / -samefile soubor.txt
/home/user/soubor.txt
/home/user/soubor_link.txt

Jak zjistit, které datové extenty patří k souboru

user@stroj:~$ sudo btrfs-debug-tree /dev/sda1 | grep -A2 22890902
                tree block key (22890902 INODE_ITEM 0) level 0
                tree block backref root 256
        item 28 key (433267265536 EXTENT_ITEM 4096) itemoff 2516 itemsize 51
--
                location key (22890902 INODE_ITEM 0) type FILE
                transid 1064905 data_len 0 name_len 10
                name: soubor.txt
--
                location key (22890902 INODE_ITEM 0) type FILE
                transid 1064906 data_len 0 name_len 15
                name: soubor_link.txt
--
                location key (22890902 INODE_ITEM 0) type FILE
                transid 1064905 data_len 0 name_len 10
                name: soubor.txt
--
                location key (22890902 INODE_ITEM 0) type FILE
                transid 1064906 data_len 0 name_len 15
                name: soubor_link.txt
--
        key (22890902 INODE_ITEM 0) block 433267253248 (105778138) gen 1066189
        key (22890986 INODE_ITEM 0) block 433404981248 (105811763) gen 1065939
        key (22891077 EXTENT_DATA 0) block 432613801984 (105618604) gen 1065005
--
        item 0 key (22890902 INODE_ITEM 0) itemoff 3835 itemsize 160
                inode generation 1064905 transid 1064909 size 6 nbytes 6
                block group 0 mode 100644 links 2 uid 1001 gid 1001 rdev 0
--
        item 1 key (22890902 INODE_REF 54530) itemoff 3790 itemsize 45
                inode ref index 40018 namelen 10 name: soubor.txt
                inode ref index 40019 namelen 15 name: soubor_link.txt
        item 2 key (22890902 EXTENT_DATA 0) itemoff 3763 itemsize 27
                generation 1064909 type 0 (inline)
                inline extent data size 6 ram_bytes 6 compression 0 (none)

Poznámka: Originál blogpostu je zde

       

Hodnocení: 100 %

        špatnédobré        

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

Komentáře

Vložit další komentář

Heron avatar 22.3.2017 10:27 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Na základě tvého upozornění jsem rmlint zkoušel a bez varovaní smazal duplicitní soubory (v testovacím adresáři, což byl repositář rmlintu ;-) ). Nevím, zda způsob, že se nejdřív vygeneruje skript + json data a ten až potom udělá danou akci, je ten nejšťastnější.

Asi by byl rozumnější nástroj typu hardlink nebo fdupes a místo ln nebo rm to předělat na cp --reflink.
22.3.2017 12:34 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Přiznám se, že si nejsem jist, jestli jsem pochopil co jsi vlastně spustil, s jakými parametry a co ti to udělalo. Ale s ohledem na kontext předpokládám, že máš na mysli pravděpodobně to, že je matoucí, když se ti v místě kde to spouštíš vytvoří spustitelný skript, který má podobné jméno jako binárka co ho generuje, ale dělá něco úplně jiného.

Z toho co píšou na wiki k Btrfs jsem vyrozuměl, že fdupes pouze vyhledá soubory vhodné pro deduplikaci a pak je nutné použít něco jiného (tam uvádí duperemove), což by znamenalo že by to bylo stejně nutné obalit nějakým skriptem.

Jinak jsem se po delší době kouknul co je v kernelu ohledně Btrfs nového a jsem natěšený na jádro 4.11, protože do něj byla implementovaná poměrně slušná porce opravných patchů. A btrfs-progs taky pěkně poskočilo (aktuální verze je 4.10.1, ale v Debianu je zatím 4.9.1)
Heron avatar 22.3.2017 12:57 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Přiznám se, že si nejsem jist, jestli jsem pochopil co jsi vlastně spustil, s jakými parametry a co ti to udělalo.
Spustil jsem rmlint (bez parametrů, nebo jen s ./ a asi i progress), ten vygeneroval sh skript a json. Spustil jsem ten sh a ten automaticky smazal nalezené duplicitní soubory. Čekal bych, že defaultní akce bude nějaká trochu neškodná (hardlink nebo reflink, pokud to detekuje cow fs). Nečekal jsem, že to duplicity rovnou maže.
Z toho co píšou na wiki k Btrfs jsem vyrozuměl, že fdupes pouze vyhledá soubory vhodné pro deduplikaci a pak je nutné použít něco jiného (tam uvádí duperemove), což by znamenalo že by to bylo stejně nutné obalit nějakým skriptem.
fdupes umí duplicitní soubory i mazat. Asi by stálo za to to předělat, aby to umělo dělat i relfinky. Nebo rovnou forknout program hardlink, pojmenovat jej reflink a upravit tak, aby místo hardlinků dělal reflinky.

Ale asi to záleží na vkusu každého soudruha. Já moc nemám rád skipty, které cosi vygenerují a až to cosi se má spustit s nějakými dalšími parametry a potom to něco udělá. Utilitky typu fdupes a hardlink jsou prudce použitelné tak jak jsou a bylo by fajn mít i utilitku pro reflink. Jednoduchou, reflink -Rv . a je to.
22.3.2017 14:10 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Aha. No tak to jsi hodně odvážný ;-)

Já jsem nejdřív vytipoval na co to aplikovat (co mě bude nejmíň bolet když to neklapne) a pak jsem použil příkaz tak jak byl uveden na wiki pro Btrfs. Pak jsem prozkoumal co je v tom skriptu, a teprve pak jsem ho spustil.

Jinak pokud jde o utilitu reflink - není nic snazšího. Stačí udělat wrapper právě na rmlint, který přesně tohle dělá, když použiješ clone.
22.3.2017 14:19 chrono
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Ak sa má ten skript najskôr preskúmať, asi by bolo rozumné pridať na začiatok nejaké varovanie a exit (aby to musel používateľ vymazať, ako to robia niektoré iné programy/skripty), prípadne, aby musel zadať nejaký parameter (ako to robí napr. program convmv).
Heron avatar 22.3.2017 15:37 Heron | skóre: 51 | blog: root_at_heron | Olomouc
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
No tak to jsi hodně odvážný ;-)
Testovací virtuálka. Na ostro bych to nepouštěl, nejsem blázen.
Jinak pokud jde o utilitu reflink - není nic snazšího. Stačí udělat wrapper právě na rmlint, který přesně tohle dělá, když použiješ clone.
Ok, ještě na to mrknu.
cezz avatar 24.3.2017 11:58 cezz | skóre: 24 | blog: dm6 | Žilina
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Clanok pekny, zrejme skusim nejaku utilitu postvat na moje data, nech zistim kolko duplicitnych suborov mam, sam som zvedavy.

Jedna vec ma tak trochu prekvapuje - preco riesis RAID1 na laptope? Nebolo by lepsie tie peniaze vrazit do extra kapacity na tom ulozisti a mat proste poriadne nastavene zalohovanie laptopu? RAID ti riesi len zlyhanie disku (aj to len velmi specificke zlyhanie, kde zaroven neodidu obidva disky) a dalsie rizika ako kradez/strata, utopenie pad, poziar a kto vie co este mas neporiesene. Chapem, ze uloziste nie je online 24/7 ale zalohy par krat tyzdenne by ti IMHO mali stacit. (a ak nie, take data nemozes mat len na laptope anyways) Za cenu jedneho 500GB SSD by si pravdepodobne mohol mat lacny NAS, ktory bude bezat 24/7 a s nastavenymi zalohami mozes tie dva SSD prepnut na RAID0 pre extra kapacitu, ked uz ich mas.
Computers are not intelligent. They only think they are.
24.3.2017 14:20 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Odpověď je prostá - opravdu nemám čas a chuť řešit situaci s chcíplým SSD, sháněním nového a reinstalací všech dat. Ale o tom jsem už psal před třemi lety – ostatně, v blogpostu je na ten zápis link.

Na zálohy a data, která nutně nepotřebuji mám pořádný stroj a ně nějaký uprděný NAS z Alzy.
Josef Kufner avatar 25.3.2017 22:37 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Problém s reinstalací by řešila záloha, která se dá ze zálohovacího serveru vytahnout a strčit do nového notebooka. Tedy zálohovat na disk stejný jako je v notebooku a serveru ho mít v RAID1 s dalším diskem. Trochu to komplikuje inkrementální zálohy, ale to by se dalo pořešit. Recovery by pak byla jen unplug, plug and play.
Hello world ! Segmentation fault (core dumped)
25.3.2017 22:59 Kate | skóre: 8
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Na stranu druhou, to mu nevyřeší úmrtí SSD v terénu nebo při delší době mimo vlastní zálohy (třeba dovolená). S RAID1 mu odejde jedno SSD a může vesele pokračovat.
cezz avatar 27.3.2017 12:18 cezz | skóre: 24 | blog: dm6 | Žilina
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Ja osobne problem s reinstalaciou riesim zalohou $HOME a plus ked chcem by fancy, tak par ansible subormi na nastavenie desktopu podla mojich preferencii. Obnova systemu je porovnatelne dlha a poskytuje mi to pomerne jednoduchy sposob ako upgradovat/zmenit distribuciu alebo cely desktop.

Byvali casy ked som mal kopec specifickej konfiguracie v /etc/, custom kernel a podobne. (zvycajne koli nie velmi standardnemu HW) Tam by som urcite zalohoval aj casti systemu, lebo clovek s tym casto stravil hodiny kym to ako-tak chodilo. Teraz uz si davam pozor pri vybere HW plus distribucie celkom pokrocili v tomto smere, takze to zvycajne funguje automagicky out of the box a zalohovat (a obnovovat) system uz mi netreba.

Ked ale niekto proste potrebuje nerusene pracovat aj s jednym odidenym diskom, tak nevidim problem v pouziti RAID1 aj na laptope. Riesi to jednu dost specificku poruchu a je kopec inych poruch ktore ten RAID1 neprezije (ja uz som teda videl RAID zlyhat vselijako aj potichu zahadzovat cast zapisu) ale ked mas na to peniaze a je to pre teba take dolezite, tak to neuskodi.
Computers are not intelligent. They only think they are.
cezz avatar 27.3.2017 11:58 cezz | skóre: 24 | blog: dm6 | Žilina
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Inak povedane, ten RAID1 tam mas primarne koli uptime, nie ako zalohu dat. To sa da celkom pochopit. Z textu som mal skor pocit, ze je to problem financny a preto mi to nedavalo zmysel, kedze ten RAID1 na SSD musi byt drahsi ako nejaky lacny "NAS z Alzy" a tiez je to horsia zaloha.

Teraz uz to dava zmysel, diky za odpoved.
Computers are not intelligent. They only think they are.
27.3.2017 15:13 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Je to notebook. Vysoký uptime ve mě vyvolává spíš křeče u žaludku, než nadšení. Btrfs raid1 není totéž co klasický md raid. Dražší řešení to sice je, ale jak uvedla o kousek výše Kate, smysl je především v tom, že mě nevykousne selhání jednoho z těch dvou SSD. SSD diskům nevěřím. Umírají náhle, nečekaně a bez příznaků.

Na zálohy mám stroj doma. Ovšem tam mě velká investice teprve čeká. Zatím v něm mám pozice pouze pro 10 disků. (6 deska + 4 řadič). Na víc zatím nemám – fyzicky totiž mohu usadit 12x 2,5 palcových disků + 8x 3,5 palcových disků
27.3.2017 16:51 Kate | skóre: 8
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
No, po tom co kamarád přišel o HDD v laptopu jenom drcnutím do desky stolu při vstávání věřím u přenosných zařízení spíš těm SSD. Ale potřebu redundance chápu, jedno mrtvé SSD v relativně novém laptopu už jsem viděla taky :)
27.3.2017 16:57 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Ano. I rotační HDD umí umřít nehezkým a rychlým způsobem. Proto SSD jo, ale jedině sichrované na úrovni FS. Původně jsem měl druhý ssd disk místo mechaniky, ale pak mě napadlo, jestli neexistuje nějaký ten řadič na mSATA, no a taky že jo. Stejně jsem potřeboval udělat upgrade, tak jsem to spojil, box na 2,5 disky mám v docku (občas se to hodí) a místo něj mám zase DVD.
Josef Kufner avatar 28.3.2017 22:09 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Já raději notebook, který je opravdu přenosný. Tam se sotva vleze ten první disk.
Hello world ! Segmentation fault (core dumped)
29.3.2017 07:00 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Jestli nosím na zádech 2 kila nebo 2,5 kila. To už je fuk. Jó, něco jiného je notebook ve fešácké brašně přes rameno. Tam se pozná každé deko - velice rychle jsem ji přestal nosit - boční namáhání páteře je velice zákeřné.
29.3.2017 13:09 Kate | skóre: 8
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Můj má 1,5 kila, tam už je ten rozdíl znát :) Škoda že se tam víc jak jeden M.2 nevejde. Jinak rovnoměrné zatížení s brašnou většinou řeším kabelkou křížem, ale to asi není nic pro tebe :D
29.3.2017 14:51 Aleš Kapica | skóre: 47 | blog: kenyho_stesky | Ostrava
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Příloha:
Můj má 1,5 kila, tam už je ten rozdíl znát :) Škoda že se tam víc jak jeden M.2 nevejde. Jinak rovnoměrné zatížení s brašnou většinou řeším kabelkou křížem, ale to asi není nic pro tebe :D
Tak řešení druhou brašnou křížem by průchozí bylo, což o to. Ovšem horší by bylo jejich rovnoměrné vybalancování. Jak vidno z přiloženého snímku, páteř už lehce deformovaná a opravdu stačí málo k tomu aby to začalo být znát. U batohu je celkem jedno, jestli tam mám jenom notebook, nebo dalších 20 kilo olova na přetavení navíc.
Josef Kufner avatar 30.3.2017 12:58 Josef Kufner | skóre: 68
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Rozdíl mezi 1½ kg a 2 kg je znát hodně. Je to akorát ta hranice, kdy se to ještě nezdá být těžké.

S malou brašnou přes rameno jsem jednu chvíli experimentoval, ale velice rychle jsem se vrátil k batohu. Nechápu, jak někdo může tak nepraktické zavazadlo používat. Pořád to někde poskakuje, překáží, tahá, nevyvážené to je, … Takže mám dva batůžky, jeden je větší komprimovatelný (pohodlně se tam vlezou desky na A4 a umí se nafouknout na víkendové zavazadlo) a druhý velmi malý, velmi lehký, když s sebou chci jen svačinu a případně deštník.
Hello world ! Segmentation fault (core dumped)
cezz avatar 30.3.2017 11:00 cezz | skóre: 24 | blog: dm6 | Žilina
Rozbalit Rozbalit vše Re: rmlint - řešení duplicit
Ja som videl mrtve HDD, ked kamarat drzal v ruke laptop za okraj prave tam kde je HDD a ten tlak, naviac znasobeny tym, ze to bola v principe paka sposobila ze sa kryt jemne prehol, zatlacil na HDD a kryt HDD nasledne zatlacil na rotujuci disk. Vydalo to zaujimavy zvuk a bolo po datach.. :D

Tiez som toho nazoru, ze v laptope skor prezije SSD, ale zalezi ako ho kto pouziva.
Computers are not intelligent. They only think they are.

Založit nové vláknoNahoru

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