Jaderné noviny – 6. 5. 2009

10. 6. 2009 | Jirka Bourek | Jaderné noviny | 3147×

Aktuální verze jádra: 2.6.30-rc4. Citáty týdne: John Curran (Microsoft), Al Viro, Eric Biederman. Podcast se shrnutím LKML. Návrat DevFS. Dlouhá diskuze o dlouhých jménech. Dvě strany reflink().

Obsah

• Aktuální verze jádra: 2.6.30-rc4
• Citáty týdne: John Curran (Microsoft), Al Viro, Eric Biederman
• Podcast se shrnutím LKML
• Návrat DevFS
• Dlouhá diskuze o dlouhých jménech
• Dvě strany reflink()

Aktuální verze jádra: 2.6.30-rc4

Současné vývojové jádro je 2.6.30-rc4 vydané Linusem (který se vrátil ke starému principu „těsně poté, co vyjde LWN“) 29. dubna. Změny tentokrát zahrnují návrat Tuxe jako maskota jádra a celou hromadu oprav. Navíc byl změněn kód tohoto vydání na „Mstivý pásovec“ [Vindictive Armadillo]. Všechny detaily lze najít v kompletním changelogu.

Patche dále proudí do repozitáře hlavní řady; téměř všechno jsou opravy, včetně jedné od autora LWN Jakea Edge, která řeší některé problémy znáhodňování adresového prostoru diskutované v bezpečnostní rubrice LWN minulý týden.

Během tohoto týdne nevyšly žádné stabilní aktualizace 2.6.29. 2. května jsme viděli aktualizace 2.6.27.22 a 2.6.28.10. Obsahují opravy v celém stromě (58 a 88 patchů v uvedeném pořadí); některé z těchto oprav se týkají chyb, které mají přiřazeno CVE číslo, takže uživatelům je doporučeno aktualizovat. Navíc: POZNÁMKA: toto je POSLEDNÍ aktualizace série 2.6.28, takže všem uživatelům je v tomto okamžiku velmi silně doporučováno aktualizovat na řadu 2.6.29! 2.6.27 bude nadále lidmi ze stable týmu udržováno ještě po nějaký čas.

Citáty týdne: John Curran (Microsoft), Al Viro, Eric Biederman

Byli jsme schopni zkrátit dobu vypínání o 400 milisekund tím, že jsme nepatrně zkrátili WAV soubor s hudbou při vypnutí.

-- John Curran (Microsoft); doba bootu již není předmětem soutěžení

Nástroje Nejsou Božstva, Která Je Potřeba Potěšit. Předmět, který v podstatě říká "$NÁSTROJ je rozzlobený!!!" je naprosto k ničemu.

-- Al Viro

Podle několika hlášení, která jsem slyšel, skutečná chyba není v linuxovém jádře, ale spíše to vypadá jako útok odepření služby [Denial of Service, DoS] proti implementaci http://uscode.house.gov/. S útočníky, kteří jsou schopni vložit několik nesmyslných hodnot a způsobit spoustu zmatků.

V Linuxu obcházíme mnoho chyb z mnoha různých zdrojů a tohle může být místo, kde bychom mohli obcházet chyby někoho jiného. Nezdá se to být situace, kde by někomu vadil neošetřený exploit, takže nemusíme chvátat. Navíc funkce byla po dlouhou dobu na všech místech stejná a všechny části jsou přinejmenším teoreticky dostupné veřejné revizi. Teď by tedy mohlo být rozumné to veřejně probrat.

Jediný důvod pro utajování, který vidím, je pokud jedna společnost uzavře nekalou dohodu s jinou společností, v takovém případě ovšem nevidím důvod, proč by břemeno údržby vyplývající z tohoto rozhodnutí mělo padnout na linuxovou komunitu jako celek.

-- Eric Biederman

Podcast se shrnutím LKML

Jon Masters experimentuje s nápadem vytvořit krátký podcast se shrnutím diskuzí v e-mailové konferenci linux-kernel. První pokus [MP3] je necelé čtyři minuty dlouhý; obsahuje stručná shrnutí diskuzí o DRBD, GFP_PANIC, zneužití popisovačů souborů a dalších. Doufám, že to bude užitečné někomu, kdo nemůže číst LKML každý den. Včera zabrala příprava 15-20 minut, což lze dělat pravidelně za předpokladu, že to k něčemu bude. Říkám si, že LKML čtu bez ohledu na to, jestli poté nahraju shrnutí, nebo ne. Pokud se to ujme, zkusím dát dohromady malý tým, se kterým bych se o tuto práci podělil.

Návrat DevFS

Snaha dosáhnout kratších časů bootování vedla v jádře k mnoha změnám. Na některé, jako je paralelizace inicializace USB, jsme se dívali minulý týden, protože některým uživatelům způsobily problémy. Nicméně další, jako je nedávno navržený devtmpfs, mají jinou sadu problémů. I když může nabídnout dobré řešení, co se redukce doby bootu týče, čelí devtmpfs poměrně neoblobnému odporu, alespoň částečně proto, že některým lidem připomíná vlastnost, která byla z jádra dříve vyříznuta, a to devfs.

Základní myšlenka je vytvořit tmpfs brzy během inicializace jádra, předtím než je inicializováno jádro ovladačů [driver core]. Poté, jakmile se každé zařízení registruje v jádře ovladačů, by bylo možné jeho hlavní a vedlejší číslo a jméno použít k vytvoření záznamu v tomto souborovém systému. Nakonec je připojen kořenový souborový systém a tmpfs může být připojeno do /dev.

To má mnoho výhod, z nichž všechny pocházejí z faktu, že není potřeba žádná podpora z uživatelského prostoru k tomu, aby bylo možné získat fungující adresář /dev. Se současným přístupem založeným na udev je potřeba rozumně funkční prostředí uživatelského prostoru, aby v něm udev mohl fungovat. Ve zjednodušených případech bootu – jako je například při používání záchranných nástrojů nebo jaderného bootovacího parametru init=/bin/sh – je potřeba mít funkční adresář /dev/, konkrétně kvůli dynamickým číslům zařízení. Také by to bylo užitečné pro embedded zařízení, které nepotřebují nebo nechtějí kompletní uživatelský prostor.

První reakcí Andrewa Mortona bylo pobavení: Lol, devfs. Greg Kroah-Hartman, který je společně s Kayem Sieversem a Janem Blunckem autorem patche, přiznal, že do určité míry je to devfs: No, je to devfs ,udělané správně‘, doufejme, že bez problémů s vfs, které mělo starší devfs :) Andrew má ale obavu, že „devfs2“, jak ho nazývá, je krok zpátky:

Myslím si, že přepis devfs Adama Richtera (který, pokud si dobře vzpomínám, je založený na tmpfs), by tyto věci vyřešil. Nikdy ale nebyl dokončen a přišel, když už bylo rozhodnuto.

Opravdu nechápu, k čemu potřebujeme devfs2. Jaké problémy mají lidé s existujícím návrhem?

I když jsou ostatní výhody důležité, Greg odpověděl tou, která se týká hlavního argumentu pro devtmpfs:

Rychlost bootu, rychlost bootu, rychlost bootu.

Jo, a taky zjednodušení init skriptů a ušetřením spousty práce embedded systémům, které se snaží správně implementovat dynamický /dev (viděli jste, co dělá Android, aby nemusel dodávat udev? To je děs...)

Alan Cox si nicméně tak jistý není. Jeho argument je, že přesunutí této funkce zpět do jádra není nic jiného než snaha zamaskovat problém v uživatelském prostoru při zvýšení spotřeby jaderné, tedy nestránkovatelné paměti. Další si myslí, že jádro by prostě mělo bufferovat uevents – zprávy generované jádrem, které se posílají udevu při změně stavu zařízení – do doby, než je nastartován udevd. To ale neřeší problém synchronizace: uživatelský prostor musí stále čekat na zaplnění hierarchie /dev.

Problém se současným schématem spočívá v tom, že vypočítávání zařízení se v podstatě provádí dvakrát – jednou v jádře, když je zařízení registrováno, a podruhé to dělá v uživatelském prostoru udevd, když nastartuje. Informace o zařízení, které jádro nashromáždilo, se ztrácí. Když se udevd inicializuje, prochází adresář /sys/, hledá v něm zařízení a následně pro ně vytváří uzly. To může na složitém systému trvat 1-2 vteřiny – což je řádově dvojnásobek doby bootu jádra. Co je ale horší, žádné procesy v uživatelském prostoru nemohou nastartovat, dokud neproběhne „coldplug“. Při používání devtmpfs bude již existovat fungující /dev, který může ostatní kód v uživatelském prostoru použít, takže „coldplug“ může běžet paralelně.

Ve vlákně bylo navrženo několik dalších metod řešení problému, ale Kay byl u většiny schopen ukázat, proč ve skutečnosti problém neřeší. V některých případech bylo chování devfs chybně přičítáno devtmpfs, ale tyto dva systémy jsou značně odlišné. Nové schéma by pro každé zařízení vytvářelo uzly patřící rootovi s právy 0600. Tím by se odstranila značná část složitosti devfs. Jak to říká Kay:

Neimplementujeme nic bláznivého, na rozdíl od toho, co dělal devfs ve svých pozdějších verzích – neděláme žádné modprobe vám za zády, žádné prohledávací háčky, žádné stupidní nové schéma pojmenovávání, žádné nové typy souborového systému, které je potřeba registrovat.

Christoph Hellwig měl proti tomuto návrhu také námitky. Část jeho stížnosti se týkala toho, jak rychle bylo devtmpfs přidáno do stromu linux-next, ale také to vidí jako vracení devfs zpět do jádra:

V podstatě to znovu zavádí devfs pod jiným jménem a z pohledu na implementaci bych řekl, že to sice není tak špatné, jako Goochův originál, ale je to rozhodně horší než přepis Adama Richtera, který jsme nakonec nikdy nezačlenili.

Nyní bychom mohli chtít revidovat rozhodnutí ponechat veškeré pojmenovávání zařízení na démonovi v uživatelském prostoru, protože se to v určitých situacích ukázalo být poměrně křehké a jsou zjevně vidět problémy s výkonností.

Kay poukázal na rozdíly mezi devtmpfs a návrhem Adama Richtera z roku 2003. V podstatě jde o komplexnost; devtmpfs je mnohem jednodušší schéma, které do jádra opravdu přidává jenom velmi málo. Implementace má okolo 300 řádek kódu v porovnání s přibližně 3600 u devfs a 600 u první verze Adamova mini-devfs.

V očekávání další stížnosti Kay také upozornil, že politika pojmenovávání zařízení v jádře již je, nicméně udev může ignorovat hodnoty dodané jádrem, pokud je potřeba. Z jeho pohledu se tak již stalo, takže se z toho stává neplatný argument proti devtmpfs:

Jádro v současnosti obsahuje politiku pro 98 % zařízení; jestliže změníš jméno jakéhokoliv ovladače, neobjeví se v /dev pod současným jménem. To je realita již několik let a nezmění se to v blízké budoucnosti, takže kromě jádrem dodaných jmen žádná skutečná politika přejmenovávání není.

Je zjevné, že vývojáři devtmpfs hodně přemýšleli o tom, co je zapotřebí, a jak by to mohlo fungovat s existujícím kódem – jak uvnitř, tak vně jádra. Je také zjevné, že existuje určitý odpor proti návratu čehokoliv, co jenom trochu připomíná devfs. Vzhledem k tomu, že devtmpfs je opravdu poměrně odlišné a má hezký efekt na rychlost bootu, jeden by si myslel, že je pravděpodobné, že si dříve či později cestu do jádra najde. Pokud se neobjeví další námitky a testy v linux-next projdou dobře, 2.6.31 může dost dobře být verzí, do které bude devtmpfs začleněno.

Dlouhá diskuze o dlouhých jménech

Když Microsoft podal žalobu proti TomTomu, jmenoval dva patenty, které pokrývají souborový systém VFAT. To přirozeně vedlo k obnovení snahy buď (1) zneplatnit tyto patenty nebo (2) úplně odejít od VFAT. Někteří ze zúčastněných nicméně doporučovali třetí přístup: Najít cestu, jak tyto patenty obejít, přitom zachovat většinu funkcí souborového systému VFAT a zároveň se vyhnout jakémukoliv potenciálnímu porušení nároků patentu. Jak ale ukazuje nedávno zaslaný patch a následující diskuze, obcházení problémů také není přímočaré řešení, přestože se právníky podařilo uspokojit.

Patch (napsal Andrew Tridgell, ale zaslal Dave Kleikamp), přichází s changelogem:

Přidává volbu CONFIG_VFAT_NO_CREATE_WITH_LONGNAMES

Když je tato volba povolena, souborový systém VFAT odmítne vytvářet nové soubory s dlouhými názvy. Přístup k existujícím souborům s dlouhými jmény bude fungovat nadále.

Všimněte si, že changelog neposkytuje žádnou informaci o tom, proč by někdo takovou konfigurační volbu mohl chtít. Pravděpodobně slouží k následujícímu: Všechny nároky patentu na VFAT se týkají vytváření souborů s dlouhým názvem. Čtení souborových systémů s takovými jmény není patentem pokryto. Zjevně je tedy myšleno, že i když se jmenované patenty týkají implementace VFAT v Linuxu, nebudou se týkat verze, která nemůže vytvářet soubory s dlouhými jmény.

Vypadá to jako rozumný hack. Fungování s existujícími souborovými systémy VFAT je zachováno, pokud někdo nebude chtít vytvářet soubory s dlouhými jmény na straně Linuxu. U systémů, které budou používat jádro s touto volbou povolenou, bude mnohem menší pravděpodobnost, že někdo prohlásí, že porušují patenty týkající se VFAT. Možná by to mohlo být nejlepší řešení.

Patch však byl v jaderné vývojářské komunitě přijat nevlídně. Jedním z důvodů pro takto chladné přijetí bylo rozhodně obecné nepřátelství vůči systému softwarových patentů a s ním spojené nechuti se mu podrobit. Přidejte pořádnou porci nelibosti vůči patentům na VFAT – a jejich vlastníku – a není překvapení, že někteří vývojáři nepodpoří „řešení“ problému.

Větší problém je nicméně to, že patch nepopisuje skutečný problém, který se snaží řešit. Vývojáři z IBM vedli v konferenci poměrně vyhýbavou diskuzi, ale nikdo z nich nechtěl říct, o co skutečně jde. Nejvíce se k tomu pravděpodobně blíží tato zpráva od Tridge:

Nicméně, pokud budete ochotni přistoupit na to, že existují dobré netechnické argumenty pro to, aby VFAT vypadl, pak vybrat tu nejlepší cestu, jak toho dosáhnout, je zcela určitě technické rozhodnutí, a to je to, co zde můžeme diskutovat.

Bohužel nejsem schopen diskutovat žádný z ne-technických důvodů, proč by vyhození VFATu mohl být dobrý nápad. Je to k vzteku, ale tak se věci mají.

Všechny tyto řeči vytvářejí určitý pocit, že patche byly do konference zaslány z nějaké zakouřené místnosti hluboko uvnitř centrály IBM. Co je ale důležitější, nedostatek informací pro vývojovou komunitu znamená, že nemohou zjistit, jestli patch funguje. Aby takové rozhodnutí mohli učinit, musí vývojáři vědět, jaký problém je řešen a jak navrhované řešení problém odstraňuje. Tuto informaci ale nemají; místo toho mají patch, který umožňuje z jádra odstranit nějaké funkce.

Podtext této konverzace je, že nějací právníci v IBM pravděpodobně zjistili, že existuje potenciální problém. Problém může být jednoduše „tato vlastnost může přivést žaloby za porušení patentů“, bez ohledu na to, jestli jsou ty patenty platné a jestli je Linux opravdu porušuje. Pro mnoho uživatelů Linuxu může být jednoduchý fakt, že pravděpodobnost žaloby vzroste, dostatečný k tomu, aby hledali alternativy. A je také možné, že stejní právníci usoudili, že toto konkrétní opatření tyto obavy může vyřešit a že by mělo být součástí linuxového jádra.

Jestliže ale právníci opravdu dospěli k těmto závěrům, neříkají to veřejně. Jaderní vývojáři se tedy mohou jenom ptát, o co skutečně jde. Opravdu jsou do toho zapojeni právníci, nebo je tento patch jenom dílem pár programátorů, kteří se pokusili vytvořit řešení (problému, který vnímají oni) po svém? Proč nemůže firma jako TomTom sama prostě patchem odstranit funkci dlouhých jmen, když z ní mají takové obavy? Mohlo by začlenění tohoto patche do jádra vést k dalším potenciálním soudním tahanicím, o kterých se neví?

Tridge tvrdí, že je potřeba, aby si některý z hlavních vývojářů promluvil s právníkem předtím, než se o tomto patchi rozhodne. Tento přístup by mohl vést ke správnému výsledku, ale stále ponechá většinu komunity ve tmě a nespokojenosti.

Zdá se, že je zapotřebí lepší způsob. V současnosti je pro vývojáře obtížné zjistit, jestli se na algoritmus v jádře vztahuje patent, nebo ne. A pokud se shodnou, že existuje patentový problém, ti samí vývojáři jsou ve velmi špatném postavení pro to, aby zjistili, jak by mohl vypadat minimální způsob, jak tento problém obejít. V této oblasti potřebujeme pomoc. Tato konkrétní záležitost se pravděpodobně objeví znovu v jiných kontextech; pokud by bylo možné vytvořit nějaký standardní proces pro řešení právních otázek, život by byl v budoucnu jednodušší.

O IBM se říká, že má rozsáhlou dokumentaci toho, jak obcházet patenty; z nějakého podivného důvodu tato informace nikdy nebyla zveřejněna. Rozhodnutí právníků bohužel pravděpodobně také zveřejňována nebudou – vývojáři ale všechny tyto informace potřebují, aby mohli na právní problémy reagovat správně. Možná nemusí existovat jiná alternativa, než že se malé skupině vývojářů budou poskytovat informace s dohodou o nezveřejňováním [non-disclosure agreement]. Takový způsob je nechutný, ale také poměrně běžný; mnoho ovladačů zařízení je vytvořeno za této podmínky.

Linux Foundation má v současnosti NDA program zaměřený na to, aby se vývojáři dostali k dokumentaci hardwaru. Možná by bylo proveditelné vytvořit podobný program (pod záštitou Linux Foundation nebo jiné skupiny jako Software Freedom Law Center nebo Open Invention Network) pro přístup k právním informacím. V současnosti je situace taková, že někteří vývojáři si mohou promluvit s právníky svého zaměstnavatele a nikdo jiný nemá skutečné ponětí o tom, co se děje. Kvůli tomu jsou pokusy řešit právní problémy pomalé, hlasité a svárlivé. Vzhledem k tomu, že je téměř jisté, že se v budoucnu tyto problémy objeví znovu, měli bychom se zamyslet nad nalezením lepší cesty.

Dvě strany reflink()

Jedna z diskuzí, kterou autor článku Jonathan Corbet propásl na nedávném Linux Storage and Filesystem workshop, se týkala navrhovaného systémového volání reflink(). Naštěstí vývojáři souborových systémů poskytli relevantní informace v detailní výměně e-mailů, a to včetně patchů. Nyní máme navržené systémové volání, které vytvořilo více otevřených otázek než odpovědí. Vytvoření nového vnitřního systémového volání vyžaduje spoustu přemýšlení, takže se zdá, že je vhodná doba se na tyto otázky podrobně podívat.

Navržená systémová volání jsou poměrně jednoduchá:

int reflink(const char *starejmeno, const char *novejmeno);

int reflinkat(int old_dir_fd, const char *starejmeno,
              int new_dir_fd, const char *novejmeno, int flags);

Tato systémová volání fungují podobně jako link() a linkat() s důležitou výjimkou: Místo toho, aby se vytvořil odkaz na existující inode, se vytvoří nový inode, který náhodou sdílí stejné diskové bloky jako existující soubor. Po dokončení volání reflink() tedy novejmeno vypadá jako kopie starejmeno, ale skutečné datové bloky se neduplikují. Soubory jsou nicméně označeny pro kopírování při zápisu [copy-on-write], což znamená, že pokud je kterýkoliv z nich změněn, některé nebo všechny bloky se zduplikují. Změna jednoho ze souborů se tedy neprojeví v tom druhém. V jistém smyslu se reflink() chová jako nenáročná operace kopírování souboru, nicméně jak moc bude podobná kopírování, se teprve uvidí.

První otázka, která se objevila, zní: Je opravdu potřeba, aby jádro poskytovalo jak systémové volání reflink(), tak reflinkat()? Většina ostatních volání *at() je spárována s ne-at verzí, protože ta druhá tu byla dříve. Vzhledem k tomu, že unixové systémy měly po dlouhý čas link(), nelze ho odstranit bez rozbití aplikací. linkat() tedy muselo přijít v samostatném volání. reflink() je ale nové, takže ho lze stejně snadno implementovat v C knihovně jako wrapper okolo reflinkat(). Pravděpodobně to nakonec bude uděláno takto.

Hlubší diskuze však odhaluje, že jsou dva zásadně odlišné pohledy na to, jak by toto systémové volání mělo fungovat. Joel Becker, který patch reflink() zaslal, ho považuje za novou variantu systémového volání link(). Ostatní by ale byli radši, kdyby se chovalo více jako operace kopírování. Pokud považujete reflink() za odrůdu link(), pak se objevují určité implikace:

• Varianta referenční odkaz je odkaz vyžaduje, aby měl nový soubor (v co největším možné rozsahu) stejná metadata jako ten starý; konkrétně musí (po dokončení systémového volání reflink()) mít stejného vlastníka, stejně jako mají pevné odkazy [hardlink].

• Vytváření nízkoúrovňového snímku [snapshot] souborového systému (nebo jeho části) je přímočaré a jednoduché. Soubory s referenčním odkazem [reflinked file] vypadají přesně jako originály; konkrétně mají téměř stejná metadata a mohou sdílet stejný bezpečnostní kontext.

• Diskové kvóty jsou problém. Měl by se referenčně odkazovaný soubor počítat do diskové kvóty vlastníka, i když se ve skutečnosti nevyužívá téměř žádný úložný prostor navíc? Pokud ano, systém musí zabránit tomu, aby uživatel vytvořil referenční odkaz na soubor, který nevlastní; jinak by jeden uživatel mohl vyčerpat kvótu jiného uživatele. Jestliže je naopak proti kvótě účtován využitý úložný prostor uživatele, který referenční odkaz vytvořil, budou potřeba komplikované struktury ke sledování využitého místa spojeného se soubory, které jsou vlastněny někým jiným.

• Co se stane, když se změní metadata – vlastník nebo oprávnění – nového souboru? V některých případech to záleží na implementaci souborového systému; zdá se, že změna metadat by mohla vyžadovat kopírování celého souboru. Kvůli tomu by se z příkazu, jako je chmod, stala poněkud náročná operace.

Na druhou stranu, pokud je vytvoření referenčního odkazu jako vytváření kopie, situace se poněkud změní.

• Z bezpečnosti se stane komplikovanější záležitost. Vytvoření pevného odkazu nevyžaduje otravování se s bezpečnostními kontexty SELinuxu, ale referenční odkaz jako kopie by to vyžadoval. Testy práv (opět včetně testů bezpečnostních modulů) by musely být podrobnější; bylo by potřeba se ujistit, že uživatel, který vytváří referenční odkaz, má přístup ke čtení souboru.

• Problém s kvótou mizí. Pokud je referenční odkaz v podstatě kopie, pak by výsledek měl být vlastněn uživatelem, který kopii vytvořil, nikoliv vlastníkem původního souboru. Jediné, co dává smysl, je naúčtovat oběma uživatelům plnou velikost souboru. Není potřeba se obávat toho, že by jeden uživatel vyčerpal kvótu jiného, a nejsou žádné problémy s udržováním informace o využití disku aktuální.

• Změny metadat jsou řešeny přirozeně, protože soubory jsou od sebe zcela odděleny.

• Referenční odkazy již nejsou opravdové snímky; nebudou fungovat jako reprezentace souborového systému v daný čas. Uživatelům, kteří mají zájem o vytvoření nízkoúrovňového snímku, referenční odkaz jako kopie neposlouží.

Přístup referenční odkaz jako kopie by nicméně bylo možné využít v mnoha dalších zajímavých situacích; příkaz cp by mohl ve výchozím nastavení vytvářet referenční odkazy, pokud je cílový soubor na stejném souborovém systému. Díky tomu by se z cp -r stala rychlá a efektivní operace. Také by je bylo možné použít ke sdílení souborů mezi virtualizovanými hosty.

Ve shrnutí dává smysl jak režim referenční odkaz jako odkaz, tak režim referenční odkaz jako kopie. Správné řešení by tedy mohlo být implementovat oba režimy a k jejich rozlišení použít parametr flags funkce reflinkat(). Implementace obou chování bude o něco komplikovanější a tak trochu zašpiní jinak konceptuálně čisté systémové volání. To se ale občas stává, když návrhy narazí na skutečný svět.

       

Komentáře

[Aleš Kapica]

Možná jsem to blbě pochopil, ale reflink mi přijde jako pěkná kravina. Když dělám nějakou kopii, tak ji obvykle dělám proto aby ji nějak dále upravil, ovšem pokud by to byla pouze reference na původní data...

[trekker.dk]

Když dělám nějakou kopii, tak ji obvykle dělám proto aby ji nějak dále upravil

V tom ti přece ale s reflink nic nebrání.

[Filip Jirsák]

datové bloky pak mají příznak copy-on-write, tzn. při zápisu (změně dat) se udělá kopie. Pro data, která se moc nemění, je to dobrý způsob, jak šetřit místo na disku i čas při kopírování.

Třeba bych něco takového rád používal při archivaci a úpravě fotek. Do jednoho adresáře nahraju originální fotky z paměťové karty, a v jiném adresáři si pak udělám jejich kopii, mažu nepovedené, případně dělám úpravy. Po prvotní kopii hned zase spoustu špatných fotek smažu (takže fyzické kopírování jejich datových bloků je zbytečné), a většinu fotek pak ponechám beze změn (takže by teoreticky stačil hardlink). Pár fotek ale přeci jen upravím, a pak ale chci mít v původním adresáři zachovaný originál – takže hardlink použít nemůžu, nebo bych si musel pamatovat, že před úpravou musím zrušit hardlink a nahradit jej skutečnou kopií. reflink a copy-on-write tohle udělá za mne.

[Marek Chlup]

Uváděný příklad se určitě vyskytuje poměrně často. Skoro by se mi líbilo, kdyby klasické kopírování v souborových manažerech (mc, nautilus, ...) probíhalo vždy způsobem reflink.

[Non_E]

Mně taky, ale jen do té doby, kdybych nad těmi daty pustil chmod -R. Ale popravdě nemám ve zvyku si na jednom oddílu kopírovat data vícekrát, takže pro sebe reálnou využitelnost reflinku nevidím.

[Jakub Lucký]

útok odepření služby

Zvláštní překlad, nebylo by lepší psát to anglicky (nebo zkratkou)?

Ale každopádně díky za článek

[Robert Krátký]

Pravda, přidal jsem orig. i zkratku.