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 14:00 | Zajímavý projekt

Byl spuštěn Humble Down Under Bundle. Za vlastní cenu lze koupit multiplatformní hry The Warlock of Firetop Mountain, Screencheat, Hand of Fate a Satellite Reign. Při nadprůměrné platbě (aktuálně 3,63 $) také Hacknet, Hacknet Labyrinths, Crawl a Hurtworld. Při platbě 12 $ a více lze získat navíc Armello.

Ladislav Hagara | Komentářů: 0
dnes 13:00 | Nová verze

Google Chrome 62 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 62.0.3202.62 tohoto webového prohlížeče přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 35 bezpečnostních chyb.

Ladislav Hagara | Komentářů: 1
dnes 11:00 | Zajímavý článek

Článek (en) na Mozilla.cz je věnován vykreslování stránek ve Firefoxu. V průběhu roku 2018 by se ve Firefoxu měl objevit WebRender, jenž by měl vykreslování stránek urychlit díky využití GPU.

Ladislav Hagara | Komentářů: 1
dnes 08:22 | Bezpečnostní upozornění

NÚKIB (Národní úřad pro kybernetickou a informační bezpečnost) informuje o zranitelnosti ROCA v procesu generování RSA klíčů, který se odehrává v softwarové knihovně implementované například v kryptografických čipových kartách, bezpečnostních tokenech a dalších hardwarových čipech vyrobených společností Infineon Technologies AG. Zranitelnost umožňuje praktický faktorizační útok, při kterém útočník dokáže vypočítat

… více »
Ladislav Hagara | Komentářů: 1
dnes 01:23 | Zajímavý software

Příspěvek na blogu otevřené certifikační autority Let's Encrypt informuje o začlenění podpory protokolu ACME (Automatic Certificate Management Environment) přímo do webového serveru Apache. Klienty ACME lze nahradit novým modulem Apache mod_md. Na vývoj tohoto modulu bylo uvolněno 70 tisíc dolarů z programu Mozilla Open Source Support (MOSS). K rozchození HTTPS na Apache stačí nově přidat do konfiguračního souboru řádek s ManagedDomain. Minutový videonávod na YouTube [reddit].

Ladislav Hagara | Komentářů: 1
včera 14:15 | Komunita

Daniel Stenberg, autor nástroje curl, na svém blogu oznámil, že obdržel letošní Polhemovu cenu, kterou uděluje Švédská inženýrská asociace za „technologickou inovaci nebo důvtipné řešení technického problému“.

marbu | Komentářů: 9
včera 13:40 | Pozvánky

Cílem Social Good Hackathonu, který se uskuteční 21. a 22. října v Brně, je vymyslet a zrealizovat projekty, které pomůžou zlepšit svět kolem nás. Je to unikátní příležitost, jak představit nejrůznější sociální projekty a zrealizovat je, propojit aktivní lidi, zástupce a zástupkyně nevládních organizací a lidi z prostředí IT a designu. Hackathon pořádá brněnská neziskovka Nesehnutí.

… více »
Barbora | Komentářů: 1
včera 00:44 | Pozvánky

V sobotu 21. října 2017 se na půdě Elektrotechnické fakulty ČVUT v Praze uskuteční RT-Summit – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt.

… více »
Pavel Píša | Komentářů: 8
16.10. 23:44 | Bezpečnostní upozornění

V Linuxu byla nalezena bezpečnostní chyba CVE-2017-15265 zneužitelná k lokální eskalaci práv. Jedná se o chybu v části ALSA (Advanced Linux Sound Architecture).

Ladislav Hagara | Komentářů: 1
16.10. 22:44 | Komunita

Greg Kroah-Hartman informuje na svém blogu, že do zdrojových kódu linuxového jádra bylo přidáno (commit) prohlášení Linux Kernel Enforcement Statement. Zdrojové kódy Linuxu jsou k dispozici pod licencí GPL-2.0. Prohlášení přidává ustanovení z GPL-3.0. Cílem je chránit Linux před patentovými trolly, viz například problém s bývalým vedoucím týmu Netfilter Patrickem McHardym. Více v často kladených otázkách (FAQ).

Ladislav Hagara | Komentářů: 4
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (16%)
 (0%)
 (0%)
 (2%)
 (72%)
 (9%)
Celkem 43 hlasů
 Komentářů: 1, poslední dnes 11:21
    Rozcestník

    rmlint - řešení duplicit

    22.3. 09:05 | Přečteno: 1355× | Za vším hledej Linux | Výběrový blog | poslední úprava: 22.3. 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. 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. 12:34 Aleš Kapica | skóre: 46 | 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. 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. 14:10 Aleš Kapica | skóre: 46 | 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. 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. 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. 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. 14:20 Aleš Kapica | skóre: 46 | 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. 22:37 Josef Kufner | skóre: 67
    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. 22:59 Kate | skóre: 7
    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. 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. 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. 15:13 Aleš Kapica | skóre: 46 | 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. 16:51 Kate | skóre: 7
    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. 16:57 Aleš Kapica | skóre: 46 | 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. 22:09 Josef Kufner | skóre: 67
    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. 07:00 Aleš Kapica | skóre: 46 | 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. 13:09 Kate | skóre: 7
    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. 14:51 Aleš Kapica | skóre: 46 | 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. 12:58 Josef Kufner | skóre: 67
    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. 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.