Názory k článku Tao zálohování s pevnými odkazy

jakkoliv nechci zpochybnovat genialitu hardlinku obecne a genialitu toho napadu ze zalohovanim zvlast ;) zajimalo by me, k cemu opravdovi unixovi guruove jeste hardlinky normalne pouzivaji. Me se totiz hardlinky zpocatku libily, dokonce hodne moc, a to zejmena diky tomu, ze jsem si precetl, jak jsou vlastne implementovane.

Postupem casu jsem ale zacal pouzivat spis symlinky, jak na adresare, tak na jednotlive soubory, pricemz vlastnost "broken link" se mi postupem casu zacala spis libit. Castym duvodem smazani souboru (resp. odsunuti na jinou partition) je totiz nedostatek mista na disku. V pripade hardlinku by nalezeni vsech kopii nazvu souboru trvalo neumerne dlouho. "Broken symlink" ma v tomhle smeru i tu vyhodu, ze muze zustat kde je, nefunguje, ale po vraceni souboru na puvodni misto zase fungovat zacne. To je nekdy docela pohodlne...

Hardlinky na adresare by me tereticky prisly velice zajimave - podle me hlavni duvod proc neexistuji je ten, ze by souborovy strom mohl snadno prestat byt acyklicky, coz by pro radu programu (find, cokoliv -R) mohlo mit katastrofalni nasledky. Sorry jestli to clanek pise, jen jsem ho preletl ;-)

Dalsi problem je prikaz s hardlinky je prikaz du. (Prikaz df naproti tomu bude fungovat normalne)

Pokud vim, v zadne dnesni distribuci hardlinky nejsou. Zajimalo by me, k cemu dalsimu je kdo doporucuje pouzit - krome te zajimave, i kdyz trochu krkolomne moznosti vytvareni "kompletnich zaloznich kopii" ? V zasade poslednich nekolik let, kdyz jsem potreboval mit "jeden soubor na dvou mistech", tak jsem to proste zasadne resil symlinkem. Jak je to vubec s hardlinkem a uzivatelskymi pravy ? Lze pomoci nej vytvorit soubor se zcela odlisnymi pravy ? moment... test... nejde. Samozrejme - pristupova prava jsou primo vlastnost inodes... pritom zrovna moznost vytvareni kopie tehoz souboru se zcela odlisnymi pravy by unixovym systemum hodne prospela, protoze by to byla nahrazka za nektere chybejici groupwarove vlastnosti :-(

V zadne dnesni distribuci hardlinky nejsou. hm
ls -l /bin/gzip
-rwxr-xr-x 3 root root 53592 úno 31 00:01 /bin/gzip

Ono v nekterych pripadech to az tak zbytecne neni.

Pouzitie hard linkov v tomto pripade ma tu krasnu vlastnost, ze na rozne prikazy gzip, gunzip, zcat existuje len jedina binarka a pri jej spusteni sa na zaklade mena [v perle je to $0, ci to je v C argv[0] uz teraz presne nepamatam] vykona patricna akcia. Napriklad v sendmail instalaciach je "mailq" tiez iba hard linka na "sendmail". Takze tak ...

Úplně stejně se v tomto ohledu chovají symlinky a taky se tímto způsobem běžně používají, dokonce podstatně častěji než hardlinky.

Symlinky dnes jasne vedou, zvlaste diky tomu, ze vice odpovidaji tomu, co si lide predstavuji pod "odkazem".
S hardlinky na adresare mate pravdu a ackoli UNIXovy filesystem obecne by je mel umet vytvorit, ext2 a ext3 vam je vytvorit nepovoli.
Jinak dnesni distribuce hardlinky samozrejme obsahuji, napr. Mandrake 9.0 nekolik set pri defaultni instalaci, zvlaste v souborech s casovymi zonami, jako aliasy pro prikazy atd.

IMO, hard link je alias (dalsi jmeno) pro soubor,
v stejnem nebo jinem adresari (v ramci jednoho FS).
Osobne, pokud mohu, dam prednost hard linku.

Je otazkou, je-li hard linkem . a .. ;-)

Hardlinky se občas používají, když se jeden program chová odlišně, podle jména, kterým se volá. Teď mě zrovna napadá jen jeden příklad: na FreeBSD se už nějakou dobu používá jako pager less místo more. Respektive less a more jsou odkazy na stejný inode se stejným programem.

Povedal by som. ze je to hlavne historicka zalezitost. Boli casy ked sa pocital kazdy byte. Ja nie som taky stary, ale pamatam si na disky o velkosti 20MB ( ano mega-bajtov ). Nuz a v tom case uz UNIX slapal ako hodinky.

Prave na takychto malych diskoch ma pouzitie hardlinku velky vyznam. Najcastejsie sa pritom pouzival pre programy ktore na nazvu suboru vykonavali odlisnu cinnost. Napr. gzip, gunzip a gzcat su uplne identicke programy, obdobne to plati pre compress, uncompress a zcat. Urcite by sa dali najst aj dalsie. Dnes sa to riesi symbolickou linkou, to ale znamena obsadenie noveho inode, teda minimalne XXX-bajtov ( XXX zavisi od filesystemu ).

Len tak mimochodom hardlinky sa stale pouzivaju. Toto som nasiel na RedHat 7.2 ( moze sice byt ze to tam doplnil nas systemak )

ls -i /bin/gzip /bin/gunzip
304651 /bin/gunzip 304651 /bin/gzip

Ja je pouzil napriklad, kdyz jsme vydavali CD s daty,
ktera bylo mozne tridit do adresaru mnoha zpusoby.
Kdybych delal pokazde kopie, neveslo by se to na CD
(1 kopie dat byla tak asi tech 600Mb). CD se melo palit jak s Joliet tak s RR rozsirenimi. Symbolicke linky by tak nefungovaly ve Win. Pouzili jsme tedy
pevne linky a cdrecord je zachoval v tom smyslu, ze
opravdu palil jen jednu kopii dat, kazdy soubor slo
ale najit hned v nekolika adresarich.

K tomu jen poznamka - v pripade pouzit optionu -f u mkisofs stejne zpracovava i symlinky...
(uf, jsem zvedav, kolikrat na me jeste vyskoci ten rooti dotaznik :-/ )

Todle je jen prispevek do diskuse, ne pevne tvrzeni ;-)

Mam za to, ze by melo jit hardlinky pouzit na regulaci pristupovych prav: muzu mit adresar, do nejz ma pravo jen nejaky uzivatel a v nem jeden link (s pravy pro grupu/vsechny), totez pro jineho uzivatele v jinem adresari... takto by mohlo jit klasicke omezeni na tri skupiny pristupu k souboru.
(priklad: mam soubor, ktery maji mit pravo editovat dva lide a cist jen nejaka dalsi skupina)

Opravi me nekdo? A existuje zpusob, jak pristupovat k souboru, jehoz inode znam, mam na nej prava, ale lezi v adresari me nedostupnem, nebo by to z principu jit nemelo?

Velmi užitečné mohou být hardlinky při chrootování.

Nemusím totiž vytvářet kopie celého prostředí nutného pro běh chrootovaného serveru, obvykle stačí většinu z toho nalinkovat. Musím ale samozřejmě použít hardlinky, protože těch se chroot netýká -- právě proto, že ukazují na inode a nikoli na místo v adresářové sktruktuře. Symlink by se převedl na jméno v chrootovaném filesystému, čímž bychom se nikam nedostali.

Aby se mi nějaký odborník na bezpečnost nevysmál, raději dodám: není to samozřejmě jen tak, musím zajistit, aby mi člověk, který by hacknul ten chrootovaný server, nemohl mohl změnit nalinkované soubory, čímž by se změnily všude.

Tohle si teda pod pojmem zalohovani nepredstavuju. Co kdyz omylem poskodim obsah souboru a budu ho chtit ziskat zpet ze zalohy? Mam smulu.

Pokud chcete opravdove zalohovani na malem prostoru metodou copy-on-write, pouzijte napriklad LVM a jeho mechanismus snapshotu.

-Yenya

Máš naprostou pravdu. Zrovna jsem na to myslel, taková to záloha může být pěkně zrádná ... spíš bych tento mechanismus použil při vytváření backupu, i když by se dalo napsat něco sofistikovanějšího ...

No me se zda, ze nazev zalohovani opravdu neni vhodny.
Zalohovat vsechno na jedno medium asi neni to prave orechove.

Spis je to takovy system pro spravu starsich verzi.

Takze neco jako CVS.

(A sakrys, nebylo by lepsi pouzit CVS?? ;-)))

priznam se, ze jsem nepochopil tuhle vetu: "Co kdyz omylem poskodim obsah souboru a budu ho chtit ziskat zpet ze zalohy" - v cem presne je prosim te problem? podle me mam neposkozenou verzi souboru v nejakem adresari zaloha/datum-pred-poskozenim/... nebo se mylim?

predem dik

To se opravdu mýlíš. V tom "nejakem adresari zaloha/datum-pred-poskozenim/...!" máš pouze hardlink na soubor v jakési "base" záloze, který jsi si pomocí rsync právě přepsal (protože rsync v adresáři "current" na razil pouze na hardlink na to samé inode, tak že to, co mělo být výhodou celého systému, je jeho zradou...
Nebo se mýlím?

Zaujala mne teoreticka moznost udelat soubor beze jmena. To by ale mely zjistit utility pro kontrolu konzistence filesystemu a takovy inode zrusit nebo pojmenovat v /lost+found/* (ext2fs), jako \file????.chk (DOS), nebo nejak podobne. Nebo je to jinak?

Ano, PRESNE k tomu slouzi direktorar /lost+found ...

Soubor beze jmena se da treba pouzit na nejaky odkladaci soubor, ktery se po ukonceni programu automaticky smaze. Soubor se otevre s=fopen(cesta,options), pak se zavola unlink(cesta) a soubor prestane existovat v adresari, ale zustane na disku a da se s nim pracovat zapisovat do nej a tak.
Vtip je v tom, ze fopen, resp. open inkrementuje ten counter, ve kterem je pocet odkazu, takze pri unlink
je tam stale jeste jednicka. Az fclose(s) ho zase dekrementuje a tim se dostane na nulu a fyzicky se smaze. Pokud mezitim spadne system, tak ho pak najdeme v /lost+found.

Nápad linků s odlišnými právy, ale stejným "adresátem" je velmi zajímavý a určitě by byl VELMI užitečný.

Kdyz uz zalohovat jednoducho s vysokou pravdepodobnosti uspesne obnovy, tak vrele doporucuji HDUP. vid: http://www.linuxzone.cz/index.phtml?ids=29&idc=301

Možnost udělat pomocí hardlinků na disku více "virtuálních obrazů" podporuje CVS verze rsyncu volbou --link-dest. S touto volbou se rsync chová tak, že vytvoří novou kopii, kde nezměněné soubory "nalinkuje" a změněné vytvoří. Je na tom postaven zálohovací systém dirvish (perlové skripty, které nakonec spustí jednou rsync s vhodnými parametry), ten naleznete spolu s patchem pro --link-dest na http://www.pegasys.ws/dirvish. Je tam také FAQ, kde autor ospravedlňuje použití pevného disku a hardlinků k zálohování (místo LVM obrazů).

jo taky by se mohlo menit ownership na toho kdo ten hard link vytvori ;-))))