Jaderné noviny – 20. 5. 2009

17. 6. 2009 | Jirka Bourek | Jaderné noviny | 2479×

Aktuální verze jádra: 2.6.30-rc6. Citáty týdne: Christoph Lameter, Pete Zaitcev. Ve stručnosti: get_random_int(); OOM pojmenovat jakkoli jinak; Sledujeme sledovací body; Sjednocující připojení. Vydán GlusterFS 2.0. API reflink() pro tento týden. Změny API fronty požadavků blokové vrstvy. Jak být hodnější ke spustitelným stránkám.

Obsah

• Aktuální verze jádra: 2.6.30-rc6
• Citáty týdne: Christoph Lameter, Pete Zaitcev
• Ve stručnosti: get_random_int(); OOM pojmenovat jakkoli jinak; Sledujeme sledovací body; Sjednocující připojení
• Vydán GlusterFS 2.0
• API reflink() pro tento týden
• Změny API fronty požadavků blokové vrstvy
• Jak být hodnější ke spustitelným stránkám

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

Současné vývojové jádro je 2.6.30-rc6 vydané 15. května. Věci se rozhodně zklidňují, minulý týden bylo jenom asi 300 commitů. A většina z nich byla poměrně malá, i když aktualizace powerpc přinesly nějaké změny defconfigu, které vypadají poměrně velké.

Současné stabilní jádro 2.6 je 2.6.29.4 vydané 19. května se slušným počtem oprav, z nichž některé měly zjevné bezpečnostní dopady, a s nějakými vylepšeními API značkovaného síťování [labeled networking] pro uživatelský prostor. 2.6.27.24 vydané ve stejné době obsahuje menší (ale stále významný) seznam oprav.

Citáty týdne: Christoph Lameter, Pete Zaitcev

Titanik se potopil, protože na palubě bylo příliš mnoho vody. Bylo by dobré vědět, jak se tam dostala (ledovec, torpédo CIA (aha, ta ještě neexistovala) jako odplata za ošklivé chování Britů). Zpráva by ale neměla doporučovat zvýšit velikost Titanicu, protože nemůže všechnu tu přicházející vodu pojmout.

-- Christoph Lameter (díky Florianovi Micklerovi)

A i kdyby to náhodou ve skutečnosti bylo správně, je to tak neslýchané porušení dobrého stylu, že tvoje karta dobrého programátora ztrácí velký kupón a propíchne se do ní díra.

-- Pete Zaitcev

Ve stručnosti: get_random_int(); OOM pojmenovat jakkoli jinak; Sledujeme sledovací body; Sjednocující připojení

get_random_int() pro znáhodňování rozvržení adresového prostoru bylo zkoumáno v bezpečnostní rubrice LWN minulý týden, ale od té doby byly diskutovány nějaké dodatečné nápady. Výkonnost byla hlavním důvodem pro setrvání u částečného MD4 hashe, který je v současném kódu, ale jsou zvažovány i jiné možnosti. Eric Biederman poznamenal, že používání proudové šifry, jako je AES, by mohlo vyprodukovat kvalitní náhodnost bez postihu výkonnosti, ale Matt Mackall nesouhlasil: Také, jakmile se podíváš na režii plánování klíčů a otisk s-boxů v cachi, není jasné, že šifrování malých bloků softwarovým AES je v porovnání se SHA1 opravdu výhra pro výkonnost.

Willy Tarreau upozornil na to, že hashovací funkce, které se používají ke generování náhodných čísel, ve skutečnosti generují mnohem více dat, než se v současnosti využívá. Uložení výstupu half_md4_transform() (nebo výstupu jiné implementace, která používá mnohem silnější hash SHA1) a vrácení 4 bytů z celé – 128 nebo 160 bitové – hodnoty hashe pro každé volání by se chovalo mnohem lépe. Linus Torvalds má ale obavy, že předat víc z hodnoty hashe by mohlo vést ke snadnějším útokům: Osobně mám podezření, že by bylo mnohem jednodušší zaútočit na hash, když bychom předali celých 16 bytů (po několika iteracích), v porovnání s tím, co děláme teď (předat jenom malou část a pak znovu hashovat). Z této diskuze se nevynořily žádné patche, ale se současnou situací nikdo není zcela spokojen, takže se v nějakém bodě může změnit.

OOM pojmenovat jakkoli jinak. Zabiják při nedostatku paměti [out-of-memory, OOM killer] byl na této stránce předmětem zájmu mnohokrát. Christoph Lameter nicméně na adresu OOM v nedávné diskuzi vznesl dříve nevídanou stížnost:

A když jsme u toho: mohli bychom se zbavit jména „při nedostatku paměti“ a přestat vypisovat texty s tímto obsahem? To, čemu říkáme nedostatek paměti, je selhání při pokusu znovuzískat paměť nebo to, že docházejí rezervy kvůli tomu, že ji nelze znovuzískat. Většina z toho jsou interní záležitosti OS, které nemají nic společného se skutečným množstvím dostupné paměti.

Christoph říká, že uživatelé mají tendence v reakci na OOM situace přidat více paměti, zatímco skutečná oprava často spočívá někde jinde – například v opravě aplikace, která zamyká velké množství paměti. Diskutovalo se o změně OOM zpráv, aby zněly nějak jako „Není možné uspokojit požadavek na alokaci paměti a znovuzískávání z jiných zdrojů není úspěšné“, ale v současnosti nebylo nic začleněno.

Sledujeme sledovací body: Jedním z klíčových kritérií návrhu jaderných sledovacích bodů je to, že jejich dopad musí být minimální, když se nepoužívají. Jason Baron byl tedy překvapen, když zjistil, že v současné implementaci sledovacích bodů jsou argumenty těchto sledovacích bodů vyhodnoceny předtím, než se zjišťuje, jestli je sledovací bod aktivní. Připravil tedy patch, který brání vyhodnocení argumentů sledovacích bodů, které nejsou aktivní. Patch funguje, ale za určitou cenu: Vyžaduje změnu interního API sledovacích bodů.

Vůči změně API existuje odpor, hlavně proto, že lidé, kterých se tento problém týká, si myslí, že novější verze je ošklivější a že problém je ve skutečnosti důsledkem chyby v GCC. Tomu se nicméně bude problematické vyhnout; i kdyby bylo GCC brzy opraveno, starší verze tu budou ještě po dlouhou dobu. Minimalizace režie je důležitější než krása API, takže pokud někdo nepřijde s chytrým způsobem, jak problém obejít, pravděpodobně se nechtěné změně sledovacích bodů nebude možné vyhnout.

Sjednocující připojení: ke zhodnocení byla vydána nová sada patchů sjednocujících připojení [union mount] společně s nezbytnými nástroji pro uživatelský prostor. Valerie Aurora dala dohromady howto pro ty, kdo by chtěli s tímto kódem experimentovat. Informace o implementaci sjednocujících připojení vizte v tomto článku.

Vydán GlusterFS 2.0

K dispozici je GLusterFS 2.0. GlusterFS je zajímavý clusterový souborový systém, který z větší části běží v uživatelském prostoru a o kterém se tvrdí, že může škálovat až do řádu petabytů. Základní přehled vizte v seznamu vlastností. Jak velikost svazku roste nad 32 TB, z downtime kvůli fsck (kontrole souborového systému) se stává významný problém. GlusterFS žádný fsck nemá. Léčí se sám transparentně s minimálním dopadem na výkonnost. Licence je GPLv3.

API reflink() pro tento týden

Navrhované systémové volání reflink() vytváří zajímavý přechod mezi pevným odkazem [hard link] a kopií souboru. Konečným výsledkem úspěšného volání reflink() je nový, samostatný soubor – s vlastním inode – který sdílí datové bloky s původním souborem. Používá se politika kopírování při zápisu, takže oba soubory oddělené zůstávají; když je jeden změněn, změny se v tom druhém neprojeví. Toto volání má několik použití, včetně rychlého vytváření snímků, a jako určitý druh optimalizované operace kopírování. Jak bylo nicméně popsáno v předchozím článku o reflink(), objevují se neshody nad tím, jaké by mělo být chování ohledně vlastnictví souboru a s bezpečností spojených metadat.

To vede na dva případy použití tohoto systémového volání. V případě „snímku“ [snapshot] musí být bezpečnostní informace zachovány; to následně znamená, že reflink() může použít jenom vlastník souboru (nebo proces, který má dostatečné kvalifikace, aby obešel omezení daná vlastníkem). Na druhou stranu ti, kteří by chtěli použít reflink() k rychlému kopírování, by byli raději, kdyby se bezpečnostní informace chovaly jako při kopírování; uživatel, který by vytvářel referenční odkaz, by musel mít právo ke čtení původního souboru a nakonec by vlastnil ten nový.

Na chvíli se zdálo, že případ referenční odkaz jako kopie bude prostě vynechán. Pak ale Joel Becker, autor patchů reflink(), navrhl kompromis: jestliže bude proces volající reflink() vlastnit soubor nebo mít dostatečné oprávnění, použije se sémantika snímkování. Jinak bude potřeba oprávnění ke čtení a bude vytvořena nová sada bezpečnostních atributů. Cílem je pokusit se automaticky udělat ve všech situacích správnou věc.

Tento přístup nicméně také nezafungoval. Z námitky Andyho Lutomirskiho:

Je spousta systémových volání, která vyžadují nějaká oprávnění a selžou, když je volající nemá. Napadá mě ale jenom jediné systémové volání, které dělá něco jiného v závislosti na tom, kdo ho zavolal: setuid.

Prosím, prohledej web a kochej se katastrofami způsobenými magickým, na volajícím závislým chováním setuid (chyba v sendmail je pravděpodobně nejznámější). Tímto návrhem pro reflink si jenom říkáme o chyby, kde útočník přiměje privilegovaný program zavolat reflink, ale přitom nemít oprávnění (CAP_CHOWN, práva SELinuxu, to je jedno) ke kopírování bezpečnostních atributů, čímž se odkaz zpřístupní se špatnými oprávněními.

I další souhlasili, že automatická změna chování podle oprávnění volajícího není nejlepší cesta, a tak se Joel znovu vrátil k rýsovacímu prknu. 15. května se vrátil s novým návrhem. API reflink() by nyní vypadalo takto:

int reflink(const char *oldpath, const char *newpath, int preserve);

Nový parametr preserve by byla sada příznaků, které by volajícímu umožnily specifikovat, které části bezpečnostně orientovaných informací mají být zachovány. Očekávané hodnoty jsou:

• REFLINK_ATTR_OWNER: Ponechat oprávnění souboru stejná. Volající musí být vlastníkem souboru nebo mít kvalifikaci CAP_CHOWN.

• REFLINK_ATTR_SECURITY: Zachovává bezpečnostní stav SELinux/SMACK/TOMOYO. Tento příznak je platný, jenom když je také předán REFLINK_ATTR_OWNER. Pokud není předáno REFLINK_ATTR_SECURITY, nový odkaz obdrží úplně nový bezpečnostní stav, jako kdyby to byl jakýkoliv jiný nový soubor.

• REFLINK_ATTR_MODE: Libovolné bity oprávnění řízení přístupu [access control permissions] zůstávají stejné; vyžaduje vlastnictví nebo CAP_FOWNER.

• REFLINK_ATTR_ACL: Všechny ACL jsou zachovány. Funguje pouze, pokud je specifikován REFLINK_ATTR_MODE.

API by také poskytovalo REFLINK_ATTR_NONE a REFLINK_ATTR_ALL se zjevnou sémantikou. Důležité je, že pokud volající postrádá potřebná oprávnění k tomu zachovat požadované informace, volání jednoduše selže. Nebude žádné magicky se měnící chování s ohledem na kvalifikace volajícího.

Joel také navrhuje nějaké nové příznaky příkazu ln:

• -r požadavek, aby byl vytvořen referenční odkaz.

• -P říká, že volání reflink() by mělo použít REFLINK_ATTR_ALL.

• -p (malé p) je jako -P s tím, že volání opakuje s REFLINK_ATTR_NONE, když první volání selže.

Padly otázky o tom, jestli jsou tyto příznaky nutné; možná jsou zapotřebí pouze „zachovat všechno“ a „nezachovávat nic“. Joel má ale pocit, že není problém tuto flexibilitu přidat vzhledem k tomu, že argument bude do API přidán tak jako tak a proti opaku není příliš velký odpor. Ve shrnutí se API reflink(), zdá se, stabilizuje směrem k něčemu, na čem se všichni shodnou. Pro 2.6.31 je pravděpodobně pozdě, ale toto nové systémové volání bude asi připraveno pro vývojový cyklus 2.6.32.

Změny API fronty požadavků blokové vrstvy

Před jádry 2.6 byla bloková vrstva poněkud jednoduchá a neflexibilní; bylo v ní vidět hodně z prvních dnů linuxového jádra. S vývojovou sérií 2.5 přišel kompletní přepis; a od té doby samozřejmě přišlo mnoho dalších významných změn. V linuxovém blokovém API jsou ale i tak stále k nalezení kousky historie. Nicméně pokud Tejun Heo uspěje se svými návrhy, část z této historie v blízké budoucnosti zmizí.

Standardní způsob, jakým blokový ovladač získává přístup k dalšímu I/O požadavku ve frontě, je volání:

struct request *elv_next_request(struct request_queue *queue);

Tato funkce vrací požadavek, který by se podle názoru I/O plánovače měl vykonat jako další. Zajímavou vlastností elv_next_request() je to, že požadavek ponechává ve frontě; dvě rychle po sobě následující volání elv_next_request() vrátí ukazatele na stejné požadavky. Blokový ovladač může explicitně požadavek z fronty odstranit voláním blkdev_dequeue_request(), ale tento krok není nutný. Zůstane-li požadavek v čele fronty, když blokový ovladač ohlásí, že byl dokončen, bloková vrstva požadavek z fronty odstraní.

Tato vlastnost je také čím dál tím víc zbytečná. Jakýkoliv současný ovladač, který za něco stojí, zpracovává několik požadavků naráz; kvůli tomu musí sám požadavky sledovat a odstraňovat z fronty. Jenom pár ovladačů z těch, které lidé zajímají, používá model „proces na řadě“. Vzhledem k tomu Tejun dospěl k závěru, že zpracovávání požadavků na řadě je myšlenka, jejíž čas pominul, a zaslal dlouhou sérii patchů.

Většina patchů se zabývá konverzí ovladačů na režim práce „nejprve požadavek vyjmout z fronty“. To je typicky záležitost jednoduchého přidání volání blkdev_dequeue_request() na správné místo. Na několika místech (například v IDE subsystému) je to poněkud složitější, ale z větší části jsou změny přímočaré.

Jakmile je tato část hotova, kulminuje série patchů sadou změn API. elv_next_request() se ruší; pokud se chce ovladač podívat na požadavek, aniž by ho vyjmul z fronty, volá místo toho:

struct request *blk_peek_request(struct request_queue *queue);

Poté lze požadavek vyjmout z fronty voláním blk_start_request(), které nahrazuje blkdev_dequeue_request():

void blk_start_request(struct request *req);

Kromě toho, že požadavek vyjme z fronty, blk_start_request() pro tento požadavek spustí časovač, čímž mu umožní reagovat, pokud není signalizováno dokončení. Ve většině případů však budou ovladače volat pouze:

struct request *blk_fetch_request(struct request_queue *q);

což je kombinace blk_peek_request() a blk_start_request().

Je tu ještě jedna změna pod kapotou, která jde dohromady s tou výše: Jakýkoliv pokus dokončit požadavek, který zůstává ve frontě, vyvolá oops systému. To lze považovat za naprosto jasnou zprávu, že zpracovávání zpráv, které jsou ve frontě, již v Linuxu není považováno za správnou věc. Je to součástí motivace pro změnu API, která je z větší části pouhou změnou jmen: Tejun si chce být jistý, že si správci blokových ovladačů mimo strom všimnou, že se něco změnilo, a odpovídajícím způsobem zareagují.

Tyto patche prošly několika koly revizí. Nikdy není nic jisté, ale je docela možné, že by tato sada změn mohla skončit v jádře 2.6.31.

Jak být hodnější ke spustitelným stránkám

V ideálním světě by počítače měly dost paměti na to, aby se daly spustit všechny aplikace, které potřebujeme. V reálném světě jsou naše systémy vytíženy současnými desktopovými prostředími, kancelářskými balíky a dalšími programy. Takže i když jsou v moderních systémech dodávány velké paměti, nikdy se to nezdá být dostatečné. Paměť je odstránkována, aby se udělalo místo novým požadavkům, a výkonnost trpí. Částečná pomoc může být na cestě v podobě nového patche, jehož autorem je Wu Fengguang a který má potenciál věci zlepšit, pokud bude někdy začleněn.

Jádro udržuje dva seznamy nejméně používaných stránek [least-recently-used, LRU], které vlastní uživatelské procesy. Jeden z těchto seznamů obsahuje stránky, které jsou zálohovány pomocí souborů – cache stránek; druhý seznam obsahuje anonymní stránky, které jsou zálohovány swapovacím zařízením, pokud nějaké existuje. Když potřebuje jádro uvolnit paměť, nejdříve se snaží odstranit stránky, které jsou zálohovány pomocí souborů. U těch je mnohem větší pravděpodobnost, že nebyly modifikovány, a jejich I/O bývá rychlejší. Se štěstím se tedy systém, který nejprve odstraní pomocí souborů zálohované stránky, bude chovat lépe.

Mohlo by však být možné dělat věci lépe. Určité druhy aktivit – například kopírování velkého souboru – mohou paměť rychle zaplnit stránkami zálohovanými souborem. Když jádro pracuje na znovuzískání těchto stránek, je poměrně velká šance, že vytlačí z paměti i další takové stránky, které jsou pravděpodobně užitečnější – konkrétně stránky obsahující spustitelný kód budou s dost vysokou pravděpodobností zapotřebí v blízké budoucnosti. Pokud jádro odstránkuje například knihovnu C, je dost velká šance, že bude díky běžícím procesům zase rychle vrácena do paměti. Ztráta potřebných spustitelných stránek je část důvodu, proč operace zahrnující velká množství dat v souborech způsobují, že se systém chvíli poté vleče.

Wuův patch se tuto situaci snaží změnit poměrně jednoduchou úpravou: Když vyhledávání stránek, které mají být znovuzískány, narazí na souborem zálohovanou spustitelnou stránku, která má nastaven bit „odkazováno“, jednoduše bit vynuluje a jde dál. Spustitelné stránky tak získají procházku LRU seznamem navíc; to se bude dít opakovaně po dobu, kdy bude někdo danou stránku využívat. Pokud vše půjde dobře, stránky, ze kterých se spouští užitečný kód, zůstanou v RAM, zatímco ty obsahující méně užitečná data budou vytlačeny první. To by mělo vést k lepší odezvě systému.

Kód se zdá být v tuto chvíli v relativně dokončeném stavu, lze si tedy položit otázku, jestli bude v blízké budoucnosti začleněn. To však u kódu správy paměti nikdy není jednoduchá otázka. Patch se do hlavní řady klidně může dostat, ale bude přitom muset překonat nějaké překážky. První překážkou je jednoduchá otázka Andrewa Mortona:

Tak. Jak víme, že tento patch Linux zlepší?

Tvrzení jako „zdá se, že rychleji reaguje“, jsou nechvalně proslulá tím, že se obtížně vyčíslují. Bez nějakého rozumně objektivního způsobu, jakým změřit přínos nabízený tímto patchem, budou jaderní vývojáři váhat se změnou heuristik nízkoúrovňové správy paměti. Jako vždy je tu také obava z regresí; nikdo nechce zjistit, že při nějaké zátěži u velké databáze dojde ke zpomalení poté, co se tento patch dostane do jádra. Ve shrnutí: Zjistit, jestli tento druh patche opravdu situaci zlepšuje, není tak jednoduché, jak by si jeden přál.

Další problém je, že tato změna by zákeřnějším aplikacím umožnila držet data v paměti tím, že by své soubory mapovaly s nastaveným bitem „spustitelný“. Odpověď na tuto námitku je jednodušší: Aplikace, která chce získat neférovou výhodu používáním takovýchto triků, to klidně může udělat již teď. Vzhledem k tomu, že s anonymními stránkami je lépe zacházeno i nyní, daná aplikace by se současným jádrem mohla dosáhnout podobného efektu alokací paměti a přečtením celého obsahu souboru. Tam, kde se někdo opravdu obává tohoto druhu zneužití, je možné (1) použít řadič paměti a omezit její spotřebu a/nebo (2) použít SELinux a zabránit aplikacím v mapování stránek s povoleným spouštěním, které jsou zálohované pomocí souborů.

Nakonec se Alan Cox podivil, jestli je vůbec tento způsob ladění heuristik správný přístup:

Stále si myslím, že se zde zaměřujeme na špatnou věc. Neměli bychom se pokoušet o mikrooptimalizace hádání nahrazování stránek – měli bychom makrooptimalizovat výslednou výkonnost I/O. Každý z mých disků umí dát 50 MBytů/s a i s nejlepšími výtvory vývojářů Gnome by to mělo být dost k tomu, aby zbytek systému fungoval správně.

Alan se odkazuje na některé zjevné výkonnostní problémy subsystémů správy paměti a blokového I/O, které se objevily před několika lety. Na některé z těchto záležitostí bylo reagováno v 2.6.30, ale ostatní stále nebyly identifikovány ani řešeny.

Wuův patch to samozřejmě nezmění, ale i tak by mohl zjednodušit život uživatelům linuxových desktopů. Je dostatečně jednoduchý a uzavřený na to, aby si, pokud se neobjeví zjevné regrese výkonnosti u jiných typů zátěže, dříve či později našel svou cestu do hlavní řady.

       

Komentáře

[finn]

• notorická = známá
• notoricky známá = pitomost

[trekker.dk]

notorický = nenapravitelný, opakující se
notoricky známý = už ne taková pitomost

[Zdeněk Štěpánek]

ale hloupost...

notoricka = casto se opakujici

notoricky znama = casto se vyskytujici a tudiz hodne znama

P.S.: Co jsou to ty souborem zalohovane stranky pameti? Neco jako druhej swap? Nebo to jsou bloky dat nactene z regulernich souboru, typicky z binarek?

Zdenek

[trekker.dk]

P.S.: Co jsou to ty souborem zalohovane stranky pameti? Neco jako druhej swap? Nebo to jsou bloky dat nactene z regulernich souboru, typicky z binarek?

To druhé. V originále je to filesystem backed a ještě se mi nepovedlo vymyslet překlad, který by to vystihoval a zároveň nebyl na tři řádky

[petr_p]

Stránka pocházející ze souborového systému, stránka souborového systému, stránka souboru? Když si vezmu, že opakem je anonymní stránka, tak si myslím, že i stránka souboru (souborová stránka) by byla přijatelná zkratka.

[Kvakor]

Možná by stačilo "neanonymní stránky" - i když to zní dost šroubovaně, je to alespoň krátké a pochopitelné.

[finn]

Slovo pochází z latinského notus, které má význam „známý“ nebo „proslulý“.

[trekker.dk]

Slovo robot pochází ze slova robotník, přesto pod ním dnes nechápeme živého člověka. Slovo pistole pochází ze slova píšťala, přesto ji anglicky mluvící země nepovažují za hudební nástroj.

Odkud pochází slovo notus, je asi tak stejně podstatné, jako u předešlých dvou případů. Důležité, jak je používáno dnes a "notoricky známý" je slovní spojení, který se používá docela často.

[Nicky726]

+1

Přesně tak, bohužel těch, co trochu znají latinu, dost ubývá a takhle to pak dopadá. A pak tu máme nejen politiky, kteří používají cizí slova aniž by jim sami rozuměli.

[Ladicek]

Těžko se divit, když latina je mrtvý jazyk…

[Nicky726]

Ano to je. Vychází z něj však mnoho současných evropských jazyků a také hodně cizích slov. Z toho důvodu těch dvou let latiny na gymplu nelituju.

[SFS]

Za b) je spravne - souborem zalohovane stranky jsou napr. stranky s kodem spustitelneho souboru, resources ze souboru apod (soubory jsou mapovany do pameti). Je nesmysl hazet je do swapu - proste stranka se zlikviduje a kdyz je potreba, znovu se nacte ze souboru na disku.

[Semo]

Anglicky "notorious" znamena nieco uplne ine ako mame zazite my (CR+SR). Do cestiny sa to casto preklada ako "nechvalne prosluly" a nema to nic spolocne s opakujucim sa dejom. Priamy opak "famous". Len cestina a slovencina z neznameho dovodu prisla na to, ze notoricky = opakujuci sa.

[David Jaša]

Což není až tak neobvyklé. Viz třeba "pathetic" nebo "control". Furt je ten různý významový posun v různých jazycích od společného základu tak nepochopitelný?

[Ondrej 'SanTiago' Zajicek]

Me se nejvic libi 'spolupracovnik' a 'kolaborant'.

[David Jaša]

Taky pěkný. Donedávna se taky od sebe dost lišily významy slov komunita a community. A abychom nechodili ke společnému kořeni tak daleko, tak třeba význam slov okres, sklep nebo zachod se mezi češtinou a polštinou dost vtipně liší. A tady se už opravdu těžko dá tvrdit, že jeden z jazyků ta slova používá špatně.

[Robert Krátký]

Anglicky "notorious"

Díky za upozornění - nedíval jsem se na originál. Opraveno.

[alblaho]

Já tomu reflinku nějak nerozumí. To bude jako fungovat na všech souborových systémech, transparentně? Nebo to nebude v 2.6.32 fungovat nikde a postupně se začne dělat podpora do FS?

[Karry]

Taky by mě tohle volání blíže zajímalo... Podle mě s ním bude možné vytvořit spoustu srandy. Moc jsem nepobral jaká vrstva jej bude vůbec implementovat. Viděl bych to tak, že se bude jednat o hardlink s příznakem copy on write a vlastními metadaty. Na starších jádrech se ten odkaz bude chovat jako hardlink (s vlastními metadaty, což podle mě je vyloženě špatně) a na novém jádře dojde při zápisu ke zkopírování do nových inodů... Nebo jsem to pochopil špatně? Jak se to bude chovat když udělám takový odkaz na adresář?!

[kapo]

 Me to prijde jako systemova podpora pro prekrizene clustery zname z poskozenych FAT disku. Akorat, ze tady pribyde priznak pro COW.

Je to celkem zajimavy, ale obavam se vice problemu s kontrolou konzistence, nez vysledneho uzitku.

[Filip Jirsák]

Podrobněji je reflink() popsáno v předminulých Jaderných novinách.

[filbar]

Překlep:
které jsou zálohovány pomocí soubory. Ve druhém odstavci.

[belisarivs]

Christoph Lameter nicméně na adresu OOM v nedávné diskuzi nicméně vznesl dříve nevídanou stížnost:

2x nicmene vypada v jedne vete dost divne.

[trekker.dk]

Jo, to druhé nicméně tam být nemá... koukám, že se mi v tomhle díle zase jednou dařilo... :-/

[belisarivs]

No, vzhledem k delce to neni zase tak spatne.