Jaderné noviny - 24. 12. 2008

6. 2. 2009 | Jirka Bourek | Jaderné noviny | 2843×

Aktuální jádro: 2.6.28. Citáty týdne: Alan Cox, Matt Mackall, Andrew Morton. Ospravedlnění FS-Cache. Vývojové statistiky 2.6.28. Sjednocování souborových systémů spojujícím připojením [union mount]. Plány do budoucna: zapisovatelná sjednocení.

Obsah

• Aktuální jádro: 2.6.28
• Citáty týdne: Alan Cox, Matt Mackall, Andrew Morton
• Ospravedlnění FS-Cache
• Vývojové statistiky 2.6.28
• Sjednocování souborových systémů spojujícím připojením
  • Plány do budoucna: zapisovatelná sjednocení

Aktuální jádro: 2.6.28

Jádro 2.6.28 je venku, vydáno bylo 24. prosince. Mezi nejvýznamnější změny v tomto jádře patří přidání správce GPU paměti GEM, souborový systém ext4 již není "experimentální", zlepšení škálovatelnosti ve správě paměti pomocí přepracovaného vmap() a patchů škálovatelnosti odstraňování stránek, přesunutí ovladačů -staging do hlavní řady a mnoho dalších. Spoustu dalších detailů o 2.6.28 vizte ve skvělém shrnutí na KernelNewbies.

Současné stabilní jádro 2.6 je 2.6.27.10 vydané 18. prosince. Obsahuje téměř dva tucty oprav pro některé poměrně závažné problémy v 2.6.27.

Citáty týdne: Alan Cox, Matt Mackall, Andrew Morton

XFS nepatří mezi věci, do jejichž vnitřností bych se díval, protože nemám dost kuřat k obětování.

-- Alan Cox

Na téma dlouho existující jaderné zprávy "odhalena zrada!"

Většina lidí by si ve skutečnosti nemyslela, že jejich tiskárna hoří. Nicméně většina lidí si BUDE myslet, že mají vážný důvod k obavám, když tuto zprávu v dmesg uvidí poprvé. Mnoho z nich vyrazí na net hledat vysvětlení a vrátí se zmateni a ne zcela uklidněni. A alespoň jeden bezradný chlapík zavolá policii, protože si bude myslet, že je napaden.

No, tohle rozhodně odpovídá mé definici pobavení se a pokud by mým cílem pro Linux bylo, abych se pobavil na účet uživatelů, byl bych pro ponechání této zprávy[1]. Nicméně ve skutečnosti zvrhle chci, aby si lidé svou zkušenost s Linuxem užívali.

[1] K čertu, pravděpodobně bych je donutil používat git.

-- Matt Mackall

Nikdy to nebylo odmítnuto, po dlouhý čas to bylo ve stavu, kdy jsme hledali údaje, které by nám umožnily souhlasit s tím, že to, co získáme, stojí za námahu, kterou do toho dáme. To, pokud vím, nikdy nebylo přesvědčivě předvedeno. Stejně tak nebyl předveden opačný případ, takže to visí v prázdnotě.

-- Andrew Morton o FS-Cache

Ospravedlnění FS-Cache

V tom, co se musí zdát jako nikdy nekončící snaha, se David Howells znovu pokouší dostat obecný mechanismus pro lokální cachování síťového souborového systému do jádra. Nejnovější verze číslo 41 jeho patchů FS-Cache byla zaslána v listopadu a on nyní žádá, aby byla vložena do linux-next. To by znamenalo, že by tato vlastnost byla na cestě do hlavní řady v 2.6.29, ale spíše se zdá, že pravděpodobnější - pokud se tam vůbec dostane - je 2.6.30.

Nápad, na kterém FS-Cache stojí, je snaha vytvořit způsob, jakým by "pomalé" souborové systémy cachovaly svá data na lokálním disku, takže opakované přístupy by nevyžadovaly přístupy k pomalým úložným zařízením pod nimi. David pracoval na začlenění do jádra po mnoho let; náš první článek o FS-Cache se objevil roku 2004. Kanonický příklad toho, kde by tato cache mohla být užitečná, je síťový souborový systém na velmi vytíženém nebo málo propustném spojení - cena opakovaného čtení dat ze sítě může být mnohem vyšší než jejich získání z místního disku. Cache navíc může přetrvávat po rebootu, což některým souborům umožní žít lokálně po velmi dlouhou dobu.

David již však má poměrně velký a rušivý patch, který míří do 2.6.29: osobní údaje [credentials]. Tento patch se dotýká spousty kódu v jádře, konkrétně VFS vrstvy. Christoph Hellwig má obavy z toho, že jak osobní údaje, tak FS-Cache míří k začlenění naráz:

Nemyslím si, že bychom fscache chtěli již do .29. Raději bych nechal kód osobních údajů usadit během jednoho vydání a získal tak čas pro jeho důkladné revize, aby byl 100% připraven pro .30.

I když by to znamenalo zpoždění FS-Cache, Andrew Morton má větší obavy:

Nevěřím, že již bylo přesvědčivě demonstrováno, že to vůbec chceme začlenit.

Je to veeeelká hromada nového kódu, takže je opravdu potřeba, aby to prokázalo slušnou hodnotu. Mohli bychom to přehodnotit? Ještě jednou? Co z toho všeho budeme mít?

Andrew má obavu z přidání dalších věcí, které bude obtížné údržovat, aniž by přinášely něco důležitého. Používání místního disku ke cachování dat ze vzdáleného disku je užitečné jenom v několika případech; a v jiných to může věci rozhodně zhoršit. Jak to říká David: Je to kompromis: výměna zátěže a zpoždění sítě za zpoždění a zátěž vašeho disku; obětujete místo na disku, abyste vyrovnali nedostatky své sítě. Co Andrew hledá, je tlak od uživatelů, ať už to budou koncoví uživatelé, nebo distributoři, kteří by tuto vlastnost chtěli. Také by rád viděl nějaké benchmarky, které ukazují zisk z používání FS-Cache.

David trpělivě odpovídal na tyto obavy, odkazoval na některé benchmarky, které zaslal v listopadu a které ukazovaly významné úspory. Benchmarky používaly NFS nad úmyslně pomalým spojením (aby se simulovala velmi vytížená síť) a ukázaly značné úspory času potřebného pro čtení velkého souboru; vliv na dobu práce se stromem zdrojových kódů jádra byl minimální. I v případě benchmarku se stromem zdrojových kódu jádra byla však významná úspora provozu na síti.

Co je možná důležitější, Red Hat dodával FS-Cache v RHEL 5 a jsou zákazníci, kteří ji používají, stejně jako zákazníci, kteří se o její použití zajímají, na což David upozornil:

My (Red Hat) ho dodáváme v RHEL-5 a v některých vydáních Fedory. Je to však poměrně náročná práce, právě protože kód ještě není v upstreamu. Máme zákazníky, kteří ho používají, a získáváme další, kteří ho chtějí. Dokonce se zdá, že ho používají i uživatelé CentOSu (nebo si přinejmenším stěžují, když nefunguje).

I když dodávání kódu mimo strom není žádná záruka toho, že bude nějaká vlastnost začleněna - AppArmor je skvělý protipříklad - skuteční uživatelé, jejichž požadavky jsou splněny konkrétní vlastností, jsou poměrně přesvědčivý argument. David podtrhává některá zákaznická nasazení FS-Cache, například:

Máme mnoho zákazníků v zábavním průmyslu, kteří tuto cachovací infrastrukturu používají nebo by ji chtěli používat na svých vykreslovacích [render] farmách. K distribuci textur (řekněme milion a čtvrt souborů) k jednotlivým vykreslovacím jednotkám používají NFS, FS-Cache jim umožňuje omezit vytížení sítě tím, že jsou opakované požadavky na čtení z NFS uspokojeny z lokální cache vykreslovací jednotky místo toho, aby se znovu muselo přistoupit na síť.

Ve shrnutí se zdá, že na Andrewovy obavy bylo reagováno. Jestli to znamená, že je cesta do 2.6.30 volná, nebo zda se objeví další záležitosti, je otázka, na jejíž zodpovězení si budeme muset počkat další přibližně tři měsíce.

Vývojové statistiky 2.6.28

V době psaní tohoto článku se jádro 2.6.28 přibližuje poměrně blízko ke své konečné verzi, tok patchů do repozitáře hlavní řady jádra se zpomalil na pramínek. Je tedy vhodné podívat se na to, co bylo v tomto vývojovém cyklu uděláno a kde se ten kód vzal.

Autor tohoto článku pravidelně zapomíná poděkovat Gregu Kroah-Hartmanovi, který nepřestává s tou spoustou práce, která zajišťuje, že jsou tyto statistiky přinejmenším středně přesné. Takže aby to bylo vyřízeno hned na začátku: díky, Gregu!

Vývojový cyklus 2.6.28 znamenal začlenění téměř 9 000 sad změn; v tomto ohledu je tedy o něco menší než 2.6.27 (10 600) i 2.6.26 (10 100). Základna vývojářů se nicméně rozšířila; do 2.6.28 přispělo 1 262 vývojářů, což je víc, než jsme viděli u jeho předchůdců. Tito vývojáři přidali 769 000 řádků kódu a odstranili 285 000, celkový přírůstek tedy byl 484 000 řádků - relativně velké množství. Mnoho z tohoto růstu přišlo od jediného vývojáře, jak uvidíme níže.

V nedávných vývojových cyklech bylo po uzavření začleňovacího okna přijato 25 % z celkového počtu patchů. Linus Torvalds upozorňoval, že bude zpřísňovat kritéria pro patche během stabilizačního období; aby byl akceptován, bude patch muset řešit nějakou známou regresi. Pohled na 2.6.28 nicméně ukazuje, že (zatím) se do jádra od 2.6.28-rc1 dostalo 1835 patchů. Je to 20 % z celkového počtu, takže jejich přítok během stabilizačního období poklesl - ale ne o moc.

Takže odkud že tyto patche přišly? Zde je top 20 přispěvatelů do 2.6.28:

Nejaktivnější vývojáři 2.6.28

Podle sad změn David S. Miller 239 2,7 % Yinghai Lu 200 2,2 % Al Viro 154 1,7 % Bartlomiej Zolnierkiewicz 150 1,7 % Alexey Dobriyan 121 1,3 % Paul Mundt 117 1,3 % Ingo Molnár 109 1,2 % Gerrit Renker 109 1,2 % Russell King 91 1,0 % Johannes Berg 91 1,0 % Steven Rostedt 85 0,9 % Alan Cox 84 0,9 % Takashi Iwai 83 0,9 % Tejun Heo 75 0,8 % Harvey Harrison 75 0,8 % Mark Brown 75 0,8 % Suresh Siddha 73 0,8 % Joerg Roedel 72 0,8 % Hans Verkuil 71 0,8 % Eric Miao 70 0,8 %

Podle změněných řádek Greg Kroah-Hartman 127848 14,9 % Inaky Perez-Gonzalez 24084 2,8 % Mark Brown 17714 2,1 % Joseph Chan 15749 1,8 % Pavel Machek 15529 1,8 % David S. Miller 15368 1,8 % Herbert Xu 13309 1,5 % Yinghai Lu 12861 1,5 % Paul Mundt 10088 1,2 % Magnus Damm 10077 1,2 % James Smart 8103 0,9 % Gerrit Renker 7536 0,9 % Johannes Berg 7196 0,8 % Bartlomiej Zolnierkiewicz 7182 0,8 % Eric Miao 7130 0,8 % Ron Mercer 7093 0,8 % Michael Buesch 6475 0,8 % Nick Kossifidis 6380 0,7 % David Vrabel 6357 0,7 % Adrian Bunk 6289 0,7 %

Na straně sad změn David Miller přispívá spoustou práce do síťového stacku, ale většina jeho změn je tentokrát v kódu architektury SPARC. Yinghai Lu je konstantní zdroj patchů pro architekturu x86. Al Viro se na seznam vrací se spoustou pročišťovací práce v kódu VFS, user-mode Linuxu a dalších. Bartlomiej Zolnierkiewicz pokračuje v pročišťování starého IDE kódu bez ohledu na fakt, že se uživatelská základna zmenšuje. A Alexej Dobrijan přispěl prací v mnoha oblastech, hlavně v subsystému netfilteru a /proc.

Když se díváme na změněné řádky, získáme pocit, že Greg Kroah-Hartman byl tentokrát poměrně zaneprázdněný. Jak se stává, Greg ve skutečnosti většinu z daného kódu nenapsal; přišla se začleněním stromu -staging. Zdá se, že Greg, samozvaný "správce svinstva", ho obdržel významné množství. Inaky Perez-Gonzales byl zdrojem patchů přidávájících podporu pro rádio s velmi širokým pásmem a bezdrátové USB. Očekávejme, že se brzy opět ukáže; nyní pracuje na začlenění WIMAX subsystému do jádra. Mark Brown přidal ovladače pro mnoho zařízení Wolfson Micro. Joseph Chan přispěl do ovladače framebufferu a Pavel Machek přidal hrst různých ovladačů.

Takže kdo za tuto práci platil? Tabulka zaměstnavatelů 2.6.28 vypadá takto:

Nejaktivnější zaměstnavatelé 2.6.28

Podle sad změn (žádný) 1683 18,8 % Red Hat 1101 12,3 % (neznámý) 790 8,8 % Intel 654 7,3 % IBM 526 5,9 % Novell 460 5,1 % (konzultant) 227 2,5 % Oracle 206 2,3 % Sun 203 2,3 % Renesas Technology 169 1,9 % AMD 158 1,8 % Parallels 152 1,7 % Marvell 134 1,5 % (školství) 131 1,5 % Analog Devices 122 1,4 % HP 120 1,3 % University of Aberdeen 109 1,2 % Fujitsu 106 1,2 % Nokia 97 1,1 % Freescale 87 1,0 %

Podle změněných řádek Novell 159527 18,6 % (žádný) 119373 13,9 % (neznámý) 78785 9,2 % Red Hat 67972 7,9 % Intel 64108 7,5 % IBM 31289 3,6 % Renesas Technology 24900 2,9 % Sun 19926 2,3 % (konzultant) 19605 2,3 % Wolfson Micro 17697 2,1 % VIA 17210 2,0 % Marvell 14108 1,6 % Freescale 12693 1,5 % Oracle 12101 1,4 % Analog Devices 10170 1,2 % University of Aberdeen 9969 1,2 % Emulex 8112 0,9 % Nokia 7744 0,9 % QLogic 7676 0,9 % Atmel 6885 0,8 %

Obecně se tabulky zaměstnavatelů mezi jednotlivými vývojovými cykly příliš nemění. Gregův strom staging umístil Novell na vrchol sloupce podle změněných řádků, přestože tato práce v Novellu nevznikla. Jako vždycky je potřeba mít na paměti, že tato čísla jsou přibližná.

Jedna vítaná změna je první výskyt VIA. Zdá se, že tato firma myslí svou podporu Linuxu vážně, a to může být jedině dobrá věc.

Psaní všeho toho kódu je důležité, ale stejně tak je důležité revidování, testování a hlášení chyb. Pokračujme tedy relativně novou tradicí a podívejme se, kdo se v patchích objevuje se značkami, které indikují tento druh spoluúčasti, revidovateli počínaje:

Vývojáři s největším počtem revizí (celkem 83)
James Morris	12	14,5 %
Rene Herman	12	14,5 %
Matthew Wilcox	6	7,2 %
KOSAKI Motohiro	5	6,0 %
Richard Genoud	4	4,8 %
Tomas Winkler	3	3,6 %
Paul E. McKenney	3	3,6 %
Mingming Cao	2	2,4 %
Michael Krufky	2	2,4 %
KAMEZAWA Hiroyuki	2	2,4 %
Pekka Enberg	2	2,4 %
Daisuke Nishimura	2	2,4 %
Christoph Lameter	2	2,4 %
Balbir Singh	2	2,4 %
Julius Volz	2	2,4 %

V tomto bodě vidíme přibližně jednu značku Revidováno-kým [Reviewed-by] za každých 100 změn vstupujících do repozitáře hlavní řady. Naštěstí není situace v revidování tak zlá; většina revidovatelů jednoduše tyto značky do patchů, které prohlíží, nepřidává.

Čísla pro hlášení chyb a testování patchů vypadají takto:

Nejoceňovanější testeři 2.6.28

Ocenění Nahlášeno-kým Adrian Bunk 5 2,6 % Randy Dunlap 4 2,1 % Arjan van de Ven 3 1,5 % Ingo Molnar 3 1,5 % Stephen Rothwell 3 1,5 % Robert P. J. Day 3 1,5 % Stephane Eranian 3 1,5 % Daniel Marjamäki 3 1,5 % Rafael J. Wysocki 2 1,0 % Yinghai Lu 2 1,0 % Venki Pallipadi 2 1,0 % Eric Dumazet 2 1,0 % Carlos R. Mafra 2 1,0 % Wu Fengguang 2 1,0 % Zoltan Borbely 2 1,0 % Andy Wettstein 2 1,0 % Steven Noonan 2 1,0 % Alexander Beregalov 2 1,0 % Andrew Morton 2 1,0 % Alexey Dobriyan 2 1,0 % Heiko Carstens 2 1,0 % Jiří Slabý 2 1,0 % Sergei Shtylyov 2 1,0 % Johannes Weiner 2 1,0 % Mike Galbraith 2 1,0 % Hideo Saito 2 1,0 % Zvonimir Rakamaric 2 1,0 % Rik Theys 2 1,0 % Andreas Steffen 2 1,0 % Vegard Nossum 2 1,0 %

Ocenění Testováno-kým Ingo Molnar 5 2,9 % Dirk Teurlings 5 2,9 % Peter van Valderen 5 2,9 % Nicolas Pitre 4 2,3 % Matt Helsley 4 2,3 % Christian Borntraeger 3 1,7 % Rafael J. Wysocki 3 1,7 % Riku Voipio 3 1,7 % Byron Bradley 3 1,7 % Tim Ellis 3 1,7 % Kamalesh Babulal 3 1,7 % Alan Jenkins 3 1,7 % Robert Jarzmik 3 1,7 % Martyn Welch 3 1,7 % Takashi Iwai 2 1,2 % Badari Pulavarty 2 1,2 % Jeff Moyer 2 1,2 % Eric Dumazet 2 1,2 % Jesper Dangaard Brouer 2 1,2 % Ramon Casellas 2 1,2 % Markus Trippelsdorf 2 1,2 % Sitsofe Wheeler 2 1,2 % Andrey Borzenkov 2 1,2 %

V obou případech je v seznamu uveden každý, kdo obdržel alespoň dvě ocenění. Dobrá zpráva je, že ačkoliv jsou na seznamu rozhodně známá jména, objevují se také lidé, kteří nejsou známi jako jaderní vývojáři. Je zde tedy skutečně komunita testerů, která obsahuje víc než jenom vývojáře. Autor článku má podezření, že stále neděláme dostatečně dobrou práci v tom, abychom je ocenili za jejich práci, ale tato konvence je relativně nová a stále můžeme v tomto směru doufat v pokrok. Za tímto účelem - vývojáři, kteří ocenili ohlašovatele a testery, jsou:

Vývojáři vyslovující uznání v 2.6.28

Ocenění Nahlášeno-kým Jiří Kosina 9 4,6 % Ingo Molnar 8 4,1 % Adrian Bunk 7 3,6 % Bartlomiej Zolnierkiewicz 6 3,1 % Linus Torvalds 6 3,1 % Peter Zijlstra 6 3,1 % Markus Metzger 6 3,1 % Randy Dunlap 5 2,6 % Andrew Morton 5 2,6 % Yinghai Lu 4 2,1 % Venki Pallipadi 4 2,1 % Jiri Slaby 4 2,1 % Suresh Siddha 4 2,1 % Roland Dreier 4 2,1 % Patrick McHardy 4 2,1 % Mark Brown 4 2,1 % Takashi Iwai 3 1,5 % Steven Rostedt 3 1,5 % Stefan Richter 3 1,5 % Paul Mundt 3 1,5 % Thomas Gleixner 3 1,5 % Dmitry Torokhov 3 1,5 %

Ocenění Testováno-kým: Lennert Buytenhek 22 12,8 % Takashi Iwai 6 3,5 % Rafael J. Wysocki 5 2,9 % Linus Torvalds 5 2,9 % Alan Stern 5 2,9 % Alexey Starikovskiy 5 2,9 % Henrik Rydberg 5 2,9 % Matt Helsley 4 2,3 % KAMEZAWA Hiroyuki 4 2,3 % Russell King 4 2,3 % Patrick McHardy 4 2,3 % Paul Mundt 3 1,7 % Jens Axboe 3 1,7 % Theodore Tso 3 1,7 % Bartlomiej Zolnierkiewicz 3 1,7 % Jean Delvare 3 1,7 % Thomas Gleixner 3 1,7 % David Brownell 3 1,7 % FUJITA Tomonori 3 1,7 %

Rychlý grep ukazuje, že počet značek Ohlášeno-kým a Testováno-kým v patchích byl ve vývojových cyklech 2.6.27 a 2.6.28 téměř stejný. Vzhledem k menšímu množství patchů v 2.6.28 to naznačuje, že o málo větší procento patchů nyní nese tyto značky. Důraz na "něco málo" je na místě; z větší části stále neoceňujeme tu spoustu lidí, kteří pomáhali dostat 2.6.28 do formy.

Sjednocování souborových systémů spojujícím připojením

Originál tohoto článku napsal Goldwyn Rodrigues

Sjednocení souborových systémů je koncept připojení několika souborových systémů pod jedním přípojným bodem, kde výsledný přípojný bod zobrazuje logickou kombinaci všech souborových systémů. Tradičně, když je do adresáře připojen souborový systém, existující obsah adresáře je skryt a zobrazuje se obsah nejpozději připojeného souborového systému. Tyto skryté soubory jsou k dispozici pouze poté, co je souborový systém odpojen. I když existují, jsou pro uživatele nedostupné. Spojující připojení [union mount] toto překonává poskytnutím přístupu ke všem adresářům a souborům přítomných v přípojeném adresáři, dokonce i po připojení dalšího souborového systému.

V jádře jsou souborové systémy seřazeny v pořadí, v jakém byly připojeny, první připojený souborový systém je na dně zásobníku připojení a nejpozději připojený souborový systém je na jeho vrcholu. Viditelné jsou pouze soubory a adresáře z vrcholu zásobníku připojení. Se spojujícími připojeními jsou adresářové záznamy z nižších souborových systémů sloučeny s adresářovými záznamy z vyšších souborových systémů, čímž se vytváří logická kombinace všech připojených souborových systémů. Soubory stejného jména z nižšího souborového systému jsou skryty, ty z vyššího mají přednost.

Spojující připojení lze použít k aktualizaci balíčků distribuce na DVD - nad souborový systém pouze pro čtení lze připojit zapisovatelný souborový systém. Všechny nové a aktualizované soubory balíčků se poté zapíší do zapisovatelného, nejvyššího souborového systému a přitom zakryjí duplicitní soubory na médiu pouze pro čtení nebo se dokonce vymažou (to se dělá pomocí vybělení, což je popsáno níže). Uživateli to umožňuje změnit soubory v systému, přičemž jsou transparentně uloženy v obrazu. Takové nastavení lze použít k vytvoření aktualizovaného DVD nebo ke správě repozitáře balíčků s nejnovějšími balíčky pro síťovou instalaci.

V porovnání s jinými implementacemi, jako je například unionFS, se spojující připojení snaží provést veškeré sjednocování adresářových záznamů ve VFS místo vytváření nového typu souborového systému. Některé z výhod tohoto přístupu jsou:

• Jednoduchý a odlehčený návrh: Vzhledem k tomu, že všechna slučování probíhají uvnitř VFS, není potřeba žádná přídavná vrstva souborového systému, která by spravovala a slučovala metadata.
• Při připojování není potřeba, aby uživatel znovu procházel zásobník připojení: uživatel nemusí vypisovat seznam adresářů, které se účastní spojení, když zadává příkaz k připojení. Postačuje pouze přípojný bod.
• Vázané připojení [bind mount] funguje bez problémů: znovu připojit část hierarchie souborového systému do dalších přípojných bodů je vlastnost VFS.

Spojující připojení, které vyvinuli Jan Blunck, Bharta B Rao a Miklos Szeredi, je prvním krokem ke sjednocujícím připojením ve VFS. Implementace patche je podobná té v operačním systému Plan 9/Inferno. V současnosti sjednocuje jmenný prostor pouze na úrovni kořenového adresáře, a ne v podadresářích.

Aby bylo možné připojit adresáře spojujícím připojením, příkaz mount musí být modifikován, aby rozpoznával a nastavoval volby spojujícího připojení. Patche pro util-linux, které příkaz mount aktualizují, lze nalézt na ftp://ftp.suse.com/pub/people/jblunck/union-mount/

Jako příklad uvažme následující adresářovou strukturu dvou souborových systémů:

Souborový systém na /dev/sdb

/dev/sdb
    |
    |-- dir1
    |    |
    |    -- file_b1
    |-- file1
    --- link1 -> file1

Souborový systém na /dev/sdc

/dev/sdb
    |
    |-- dir1
    |    |
    |    -- file_c1
    |-- dir4
    --- link1 -> dir4

Zadání následujících příkazů provede spojující připojení:

# mount /dev/sdb /mnt
# ls /mnt
dir1 file1 link1

# mount --union /dev/sdc /mnt
# ls /mnt
dir1 dir4 file1 link1

Po spojení adresářová struktura vypadá nějak takto:

Výsledný souborový systém po union připojení

/mnt
    |
    |-- dir1
    |    |
    |    -- file_c1
    |-- dir4
    |-- file1
    --- link1 -> dir4

Odpojení adresáře /mnt odvíjí zásobník připojení souborových systémů:

# umount /mnt
# ls /mnt
dir1 file1 link1

Souborové systémy jsou v jádře skládány v pořadí, v jakém byly připojeny. Při připojování ve spojujícím připojení je nastaven příznak MNT_UNION ve vfsmnt, což umožňuje určit, že adresářové položky souborových systémů na zásobníku mají být spojeny. Když probíhá vyhledávací sekvence, pak jestliže je příznak MNT_UNION nastaven, jsou prohledány všechny adresářové položky z kořenového adresáře. Prohledávání proběhne směrem od vrcholu zásobníku souborového systému k jeho dnu, vrácen je první shodný záznam. Tímto způsobem jsou automaticky ignorovány duplikátní záznamy ze souborových systémů pod daným připojením.

Podobně je to u volání readdir(), kde jsou adresářové položky čteny od nejvyššího adresáře spojujícího přípojného bodu k nejnižšímu a shromažďovány v cache. Cache je zodpovědná za sbírání a udržování adresářových položek mezi naskládanými souborovými systémy se zpětnými voláními [callback] pro každý souborový systém. Stejně jako obyčejné soubory lze v adresářích vyhledávat [seek] a pozice, odkud proběhne následující čtení, je označena pozicí v souboru filp->f_pos. Když se čte z adresářů mezi jednotlivými souborovými systémy, je možné, že pozice souboru překročí velikost inode adresáře, kam se připojuje. V takové situaci je pozice v souboru upravena, aby byl vybrán správný adresář v zásobníku spojení. To se provádí odečtením velikosti inodu, pokud ji pozice v souboru překročí, a vybráním dalšího člena spojení.

To funguje pro souborové systémy, jako je ext2, které používají ploché adresářové soubory. Offsety položky v adresáři jsou uspořádány lineárně a jsou vždy menší, než je velikost inode adresáře. Některé souborové systémy však vrací jako offsety v adresářové položce speciální cookies, které nejsou spojeny s pozicí v adresáři ani velikostí inodu. Aktualizace file->f_pos, aby vyhověl více adresářům, u takových souborových systémů nefunguje.

Číst položky v jednom adresáři může několik readdir()/getdents() rutin. V současnosti není cache sjednoceného adresáře mezi těmito voláními uchovávána. Místo toho jsou u každého volání do cache znovunačteny dříve přečtené záznamy a ty jsou porovnány s nově načtenými záznamy kvůli duplikátům předtím, než jsou vráceny do uživatelského prostoru. Vývojáři pracují na zefektivnění tak, že cache se bude uchovávat mezi jednotlivými voláními readdir()/getdents().

Plány do budoucna: zapisovatelná sjednocení

V současnosti je sjednocení jmenného prostoru omezeno na adresářové položky kořenového souborového systému. Plán do budoucna známý jako zapisovatelné sjednocení se má přiblížit implementaci sjednocení jmenného prostoru unionfs. Slučování adresářových položek nebude omezeno na kořenový souborový systém, ale bude možné i v podadresářích. I když tyto patche byly již vyvinuty, co se hlavní řady týče, stále vyžadují nějaký čas a testování.

Při použití příkladu výše by zapisovatelné sjednocené připojení dvou souborových systémů obsahovalo toto:

Výsledný souborový systém po zapisovatelbném union připojení

/mnt
    |
    |-- dir1
    |    |- file_b1
    |    -- file_c1
    |-- dir4
    |-- file1
    --- link1 -> dir4

Všimněte si, že adresář dir1 nyní obsahuje jak soubor file_b1, tak file_c1.

Všechny zápisy jsou směřovány do nejvyššího souborového systému, pokud je připojen pro čtení i zápis. Připojení nového souborového systému na současné sjednocení přepne všechny souborové systémy níže na zásobníku do režimu pouze pro čtení, přestože sjednocený jmenný prostor se bude uživateli jevit jako připojený ke čtení i k zápisu. Všechny modifikace souboru v nižších souborových systémech se provádí pomocí kopírování při zápisu [copy-on-write]. Jestliže je otevřen soubor patřící do nižší vrstvy zásobníku, celý soubor se zkopíruje do nejvyššího souborového systému. To je známo jako kopírování výše [copy-up], při kterém je soubor zkopírován na nejvyšší vrstvu, pokud je potřeba zaznamenat jeho změnu. Když probíhá kopírování výše, je v nejvyšším souborovém systému znovuvytvořena i cesta k souboru, takže pokud je příště připojen ve sjednocení, objeví se na stejném místě. Pokud jsou při příštím sjednocujícím připojení souborové systémy připojeny ve stejném pořadí, starší soubor je při slučování adresářů zamaskován.

Přejmenování je na sjednocených připojeních řešeno pomocí -EXDEV. -EXDEV vrací operace rename(), pokud cesty zdrojového a cílového souboru leží na jiném připojeném souborovém systému. V takovém případě se program jako mv musí uchýlit ke kopírování a smazání souboru na tom souborovém systému, ze kterého byl přesunut. Na sjednocených připojeních, vzhledem k tomu, že všechny zápisy se provádí v nejvyšší vrstvě, vrací operace přesunu v adresářích na nižších vrstvách -EXDEV, což znamená, že aplikace musí soubor do nového adresáře zkopírovat. Jestliže zdrojové i cílové umístění operace rename() leží v nejvyšší vrstvě, použije se obvyklý způsob přejmenování.

Smazání souboru je řešeno speciálním typem souboru nazvaným vybělení. Bělící typ souboru je podobný záporným záznamům v adresáři [dentry]: popisuje jméno souboru, který tam není. Používá se k označení souboru, který leží v nižším souborovém systému pouze pro čtení, protože modifikovat lze pouze nejvyšší vrstvu. Vybělení nicméně vyžaduje podporu všech souborových systémů, aby bylo možné uložit a rozpoznat takový typ souboru. V současnosti je takovýto speciální soubor DT_WHT definován v include/linux/fs.h, ale nepoužívá se.

Sjednocení jmenných prostorů adresářů je obtížný úkol. Implementace ve FreeBSD se vzdaly s tím, že to bylo nazváno "zmatený kód", a i když se unionfs na krátkou dobu objevil v -mm stromě, do hlavní řady se nedostal. Vzhledem k tomu, že sjednocení je založené na cestách, je nejlépší to řešit ve VFS místo toho, aby se používal samostatný skládaný [stacked] souborový systém. Sjednocené připojení nabízí čistší a odlehčenější přístup pro sjednocování adresářů, ale přimět ho dodržovat POSIXová adresářová volání jako telldir() nebo seekdir() je stále výzva, na které se v současnosti pracuje.

Gitový repozitář, ve kterém lze sledovat sjednocená připojení, je umístěn na git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git ve větvi union-dir. Vývojáři sjednocených připojení mají v úmyslu vydávat patche v jednotlivých fázích počínaje současným patchem pro sjednocování na úrovni kořenového adresáře. Další vývoj potom povede k patchům spojeným se slučováním i na úrovni podadresářů.

       

Komentáře

[Xerces]

Tak to sjednocování souborů to je slušnej chaos No asi jsem už moc staromódní.

[Krakonoš]

Dokud máš dva, tak to ještě jde (no dva, jeden ro, jeden rw ) - to občas používám a je to super, ale víc jsem nikdy nepotřeboval a i kdyby tak to neuděl, jelikož bych se v tom ztratil ... Ale věřím, že to někdo použije

[mkoubik]

Slovo union se IMHO používá i v češtině. Překlad "sjednocení" mě donutil přemýšlet o co se vlastně jedná, ale chápu, že nalezení rovnováhy mezi anglickými a českými výrazy je někdy těžké.

A teď k věci, na tohle už existuje unionfs - používá (možná používal, nevím) se např. ve Slaxu v kombinaci ro image disku + rw ramdisk.

[mkoubik]

Aha, tak jsem si nevšiml ani, že se "sjednocení" řeší o vlákno níž, ani, že se v článku píše o unionfs. Měl bych se vyspat.

[trekker.dk]

A teď k věci, na tohle už existuje unionfs

To je pravda, nicméně přímo v článku je popsáno, proč si vývojáři myslí, že jejich řešení je lepší. (A na první pohled to vypadá, že mají pravdu.)

[kralyk z abclinuxu]

K čemu je ta featura vůbec dobrá? Má to nějakou výhodu oproti tradičnímu mountingu?

[Jendа]

Třeba že může live CD jednoduše připojit svůj FS a nad něj tmpfs? Nebo by snad šlo nad běžící systém připojit tmpfs, zkusit nějaké změny a když se to nepovede, vrátit to. Union FS teď využívá třeba SLAX a Dannix - stáhneš si zkomprimovaný FS, připojíš ho nad / a máš nový program. Až ho nechceš, tak ho jednoduše odpojíš.

[kralyk z abclinuxu]

áha jo tak, dík...

[Karel Zak]

Perfektni clanky, ale ... opravdu je nutne prekladat i veci jako je "union mount", mozna jsem divnej, ale tak jak je to v clanku je to pro mne na hranici citelnosti

[Jary]

Připojuji se. Union nepřekládat, mate to.

[Josef Kufner]

Na tohle existuje jedno krásné a čitelné řešení: v hranatých závorkách uvést originál. Vyhoví to jak těm co nerozumí překladu, tak těm co nerozumí originálu. Jen se to nesmí používat moc často (max tak 1× za 3 řádky).

[Robert Krátký]

Na tohle existuje jedno krásné a čitelné řešení: v hranatých závorkách uvést originál.

Což je přesně to, co se stalo v článku

[Filip Jirsák]

A je opravdu nutné to řešit znova pod každými Jadernými novinami, aniž by někdo přinesl nějaký nový argument?

[trekker.dk]

Je to děs, kvůli diskuzi o překládání/nepřekládání některých výrazů není místo na flame o pravopisu a překlepech.

[Filip Jirsák]

S tím musím nesouhlasit. Místo by bylo – proč nevést paralelně dva flamey (toto je můj příspěvek do diskuze, zda překládat, či nepřekládat) v jedné diskuzi, že. Jenže překladatel a redaktor na nás byli zlí a žádné překlepy nám tam nenechali…

[filbar]

Dříve tady vycházela celkem super část jaderných novin a V4L. Ta už skončila? :(