Portál AbcLinuxu, 27. dubna 2024 15:55
Aktuální verze jádra: 2.6.17. Citát týdne: Linus Torvalds. Ext3 pro velké souborové systémy. Čas na ext4? 64bitové zdroje. Škálování oken na internetu.
Aktuální předverze zůstává 2.6.17-rc6; během minulého týdne nevyšly žádné nové předverze. Od vydání -rc6 bylo začleněno několik desítek oprav, ale tempo se výrazně zpomalilo.
Aktuální -mm strom je 2.6.17-rc6-mm2. Mezi nedávné změny patří nová statistická infrastruktura pro subsystém správy paměti, virtualizované jmenné prostory pro základní funkce komunikace mezi SYSV procesy a práce na validátoru zámků.
Myslím, že zajímavé na tom je, jak se vzdalujeme od modelu "globálního vývoje" (tj. potíže vždy nastávají u 2.4.x i 2.6.x ve stejnou chvíli), a jak skutečnost, že se snažíme udržovat stabilnější situaci, může znamenat větší zapojení modelu "lokálního vývoje", při kterém prochází konkrétní subsystém vývojovou sérií, ale požadavky na stabilitu říkají, že nesmíme dopustit, aby se to dotklo stávajících uživatelů.
A ještě zajímavější (aspoň pro mě) je, že otázka by mohla znít "jak to ovlivní nástroje a infrastrukturu kompilací a konfigurace", prostě celkový průběh vývoje.
Linux podporuje velké množství souborových systémů. Ačkoliv platí, že linuxová VFS vrstva bere všechny souborové systémy jako sobě rovné, ext3 je určitě mezi rovnými na prvním místě. Ext3 je výchozí volbou mnoha distribucí, takže ho naleznete na obrovském počtu linuxových instalací. Kdyby se mělo o některém ze souborových systémů říci, že je "linuxový", byl by to ext3.
Ext3 je založen na desetiletích zkušeností s unixovými souborovými systémy. Díky tomu je relativně snadno srozumitelný a při provozu vysoce spolehlivý. V mnoha ohledech je však také patrný jeho věk. Jedním z nich maximální velikost zařízení, která dokáže spravovat. Limit je pouhých 8 TB. Dost na naše mailové adresáře i před vyházením spamu, ale přeci jen jde o limit, který už teď některé uživatele omezuje. Vzhledem k velikosti současných disků není dnes vytvoření 8TB pole žádné velké sci-fi - a postupem času to bude ještě snazší.
Tento limit má dva důvody. Prvním je používání 32bitových blokových čísel - a ke všemu se znaménkem. Ext3 kód může sledovat jen 2 gigabloky, což - při velikosti bloků 4K - udává limit 8 TB. Změna na bezznaménkový typ limit zdvojnásobí, ale to jen problém odsune přibližně o rok. Je jasné, že jsou potřeba větší bloková čísla.
Druhý problém souvisí s tím, jak ext3 sleduje bloky spojené s daným souborem. Struktura inode obsahuje pole patnácti 32bitových ukazatelů; prvních dvanáct obsahuje indexy prvních dvanácti bloků souboru. Takže když souborový systém používá 4K bloky, může prvních dvanáct ukazatelů popsat soubor až do velikosti 48kB. Přesáhne-li soubor tuto velikost, je vytvořen "nepřímý blok". Tento blok je velkým polem blokových ukazatelů, které drží indexy pro dalších 1024 bloků; 13. ukazatel struktury inode sleduje umístění tohoto nepřímého bloku. Pokud to nestačí, je 14. ukazatel použit pro dvojitý nepřímý blok - blok držící ukazatele na nepřímé bloky. A pokud to pořád nestačí, může být 15. ukazatel použit pro trojitý nepřímý blok.
Takové uspořádání se příliš neliší od toho, jak unixové systémy strukturovaly souborové systémy před dvaceti lety. Stanovuje maximální velikost souboru na 4 TB - velký, ale možná omezující pro dnešní žhavé aplikace (třeba kompletní celonárodní archivace telefonních hovorů). Funguje to dobře u malých souborů, ale čím větší soubory, tím je tato organizace méně efektivní. Udržování ukazatele na každý blok je náročné jak z hlediska využití prostoru, tak času, který trvá lokalizace konkrétního bloku souboru. A protože větší souborové systémy budou zaplněny spíše velkými soubory, začne být tato režie časem dost omezující.
Řešení těchto problémů nabízí sada patchů implementujících rozsahy [extents] a podporu 48 bitů. Patche poslal Mingming Cao; pracovali na nich však i další vývojáři - zejména Alex Tomas. Mění způsob ukládání souborů, aby systém fungoval efektivněji a bylo možné indexovat bloky na větších zařízeních.
Základem patche je podpora rozsahů. Rozsah je prostě sada bloků, které jsou v rámci souboru i na blokovém zařízení logicky souvislé. Většina současných souborových systémů se velmi snaží pro soubory alokovat souvislé bloky, aby byly I/O rychlejší, takže často jsou bloky, které jsou logicky souvislé v rámci souboru, souvislé i na disku. Kvůli tomu by mělo ukládání souborové struktury do rozsahů vyústit ve výrazné zmenšení velikosti metadat souboru, protože jediný rozsah může nahradit velký počet ukazatelů na bloky. Zmenšení metadat by mělo také umožnit rychlejší přístup.
Souborový systém ext3 připojený se zapnutými rozsahy bude s uloženými soubory pracovat postaru - pomocí blokových ukazatelů. Nové soubory budou však vytvářeny s rozsahy. V těchto souborech bude výše popsané pole s patnácti ukazateli nahrazeno novou datovou strukturou. Krátká hlavička následovaná několika výskyty této struktury:
struct ext3_extent {
__le32 ee_block; /* první logický blok, který rozsah pokrývá */
__le16 ee_len; /* počet bloků krytých rozsahem */
__le16 ee_start_hi; /* vysokých 16 bitů fyzického bloku */
__le32 ee_start; /* nízkých 32 bit fyzického bloku */
};
ee_block je zde index (v rámci souboru, ne na disku) prvního bloku pokrytého tímto rozsahem. Počet bloků v rozsahu je uložen v ee_len, a ukazatel na první z těchto bloků (tentokrát na disku) je v kombinaci ee_start a ee_start_hi. Čísla fyzických bloků uložená tímto způsobem umožňují ext3 pracovat se 48bitovými čísly bloků - dost na indexaci zařízení o velikosti 1024 PB. To by snad mělo na pár let vystačit.
U souborů s několika málo rozsahy mohou být všechny informace uloženy v inodě na disku. Při větším počtu rozsahů však dojde místo. V takovém případě se využije určitá forma nepřímého bloku; pole rozsahů ve vnitřní inodě popisuje skupinu bloků, které drží svá vlastní pole rozsahů. Strom nepřímých bloků s rozsahy může neomezeně růst, takže souborový systém zvládne i velmi velké a vysoce fragmentované soubory.
Kromě rozsahů nebylo nutné provádět příliš změn, aby byl ext3 na 48bitové adresování připraven. Znaménková 32bitová čísla bloků byla nahrazena větším typem sector_t. Trocha rezervovaného místa v ext3 superbloku byla využita pro uložení vysokých 16 bitů globálních počtů bloků. Většina sledování volných bloků v souborovém systému je prováděna pomocí čísel bloků vztahujících se k začátku skupiny bloků, takže tento kód nebylo třeba skoro vůbec měnit. Bylo nutné trochu doladit žurnálovací kód, aby si poradil s většími čísly bloků.
Výsledkem je vylepšení ext3, které umožňuje práci s daleko většími zařízeními. Stávající souborové systémy mohou nové funkce okamžitě využívat, aniž by bylo potřeba zálohovat a obnovovat. Zdá se, že je (téměř) všeobecná shoda o tom, že tyto změny dělají z ext3 lepší souborový systém. Jinou otázkou však je, jestli by měl být i nadále nazýván ext3.
Jak bylo popsáno výše, patche, které přidávají do ext3 podporu 48bitového adresování, byly dány do placu ke kontrole. Všichni souhlasí, že jsou to dobré změny, a měly by být součástí linuxového jádra. Tedy, skoro všichni souhlasí. Ale způsob, jakým by měly být začleněny, inspiroval velkou diskuzi o tom, jak by měl probíhat vývoj souborových systémů.
Někteří vývojáři, z nichž nejprominentnější je Jeff Garzik, vyjádřili obavy ze začleňování těchto změn do ext3; raději by nové funkce viděli v nově vytvořeném souborovém systému ext4. Mají pro to několik důvodů. Snad nejzásadnější je ten, že využitím rozsahů a 48bitových funkcí by vznikl souborový systém, který by již nebyl zpětně kompatibilní. Pokud administrátor povolí v souborovém systému rozsahy, bude v superbloku nastaven speciální parametr "nekompatibilní funkce". Pak už nebude možné souborový systém připojit žádným starším jádrem, které tento parametr nezná. Až doteď bylo obecně možné připojit ext3 na starších jádrech - i těch, která podporují pouze ext2 (s jedinou nepěknou výjimkou, která se týkala distributora, jenž tvrdě prosazoval SELinux).
Obavy vyvolává také celkový dopad těchto změn na stabilitu souborového systému. Protože jsou souborové systémy důležité, uživatelům se vůbec nezamlouvají "aktualizace", které přinášejí chyby nebo ovlivňují výkon. Linus o tom řekl:
Já vidím největším potíž v podpoře. JE VELMI DOBRÉ MÍT stabilní souborový systém, který využívají tisíce a tisíce lidí, a u kterého kromě údržby neprobíhá žádný vývoj.
Začlenění nových funkcí by pro ext3 nepochybně znamenalo konec časů pouhé "údržby".
S přibývajícími funkcemi je kód souborových systémů (který musí podporovat jak systémy, které nové funkce mají, tak ty, které je nemají) čím dál více komplikovaný. Objevuje se stále více kódu, který vypadá takto:
if (má_tuhle_bezva_funkci)
proveď_to_bezva_stylem();
else
proveď_to_nudně_postaru();
Takový kód se hůře čte a kód nových funkcí není tak hezky oddělen od starého, jak bylo vhodné. Kdyby však byly nové funkce v novém souborovém systému, množství těchto podmínek by mohlo být odstraněno.
A v neposlední řadě vývojáři tvrdí, že nutnost zpětné kompatibility brzdí vývoj. Oddělení vývojových systémů od stabilních by vývojářům umožnilo prosazovat nové funkce, které by chtěli implementovat. Jako příklady z praxe mohou posloužit třeba ext2 a ext3, SMB a CIFS a vytvoření libata místo natlačení podpory SATA do starých ovladačů ATA.
Je jasné, že vývojáři ext3 mají na to vše vlastní názor. Souborový systém s novými funkcemi nebude na starých jádrech fungovat bez ohledu na to, jestli se mu říká ext3 nebo ext4. A protože funkce jako například rozsahy musí být povolena administrátorem systému (za předpokladu, že to za něj potichu neudělá distributor), neměl by být nikdo překvapen, že už souborový systém na starších systémech nefunguje. Vložení nových funkcí do ext4 by prostě zpomalilo jejich přijetí, aniž by se přineslo cokoliv jiného.
Zatímco někteří jsou přesvědčeni, že osamostatnění vývoje v novém souborovém systému by usnadnilo údržbu kódu, jiní už si tak jistí nejsou. Konkrétně existují obavy, že chyby opravené v jednom systému by mohly zůstat neopravené v druhém.
Už vícekrát bylo zmíněno, že se uživatelům líbí, když jejich souborovému systému přibudou nové funkce bez toho, aby bylo nutné vše zálohovat a pak obnovovat. Přechod z ext2 na ext3 je nejlepším příkladem takového postupu; kdyby přechod na ext3 vyžadoval uložení dat a jejich obnovení na nový souborový systém, ext3 by byl přijat daleko pomaleji a ne tak všeobecně. Jak tento příklad dokazuje, vložení nových funkcí do nového souborového systému ext4 by nemuselo takovému způsobu upgradu bránit.
Vývojáři ext3 také poukazují na to, že na souborovém systému pracují už několik let a ještě nikdy nezpůsobili uživatelům Linuxu žádné velké problémy. Mají pocit, že si zaslouží trochu důvěry. Takže by raději využili nové funkce, které velmi pečlivě připravovali a důkladně kontrolovali, než aby byl ext3 naklonován na ext4 a začínalo se znovu.
Chcete-li hádat, jak to vše dopadne, můžete začít s názorem Linuse:
Upřímně řečeno si nemyslím, že by v tuto chvíli bylo možné nějak vážněji říznout do ext3. Je to hlavní souborový systém pro mnoho uživatelů a nestojí to prostě za ty obavy z nestability - pokud by nešlo o něco zcela zjevně transparentního.
Další pohled na věc od Andrew Mortona:
Přesto je pravda, že linuxové souborové systémy začínají být trošku rozvrzané a blížíme se k okamžiku, kdy bychom mohli těžit z nového, který začne na zelené louce. Mohl by být založen třeba na reiser4 - nedíval se na něj někdo? Už tu leží pár let.
Na příkladu reiser4 je však vidět, že dostat do jádra nový souborový systém nemusí být zrovna snadné. Možná k tomu vůbec nedojde, dokud nezačnou většímu počtu uživatelů vadit omezení ext3. Stávající sada zlepšení si tedy pravděpodobně cestu do jádra najde - i když není jasné, jak se bude výsledný souborový systém jmenovat.
"Zdroj" je termín, který se v rámci linuxového jádra používá pro určitou skupinu hardwarových zdrojů týkajících se I/O - především I/O paměť a porty. Ovladače zařízení alokují určité zdroje pomocí funkcí jako request_region(), ale pod touto vrstvou má Linux sadu obecných utilit pro alokaci zdrojů. A v jádře tohoto kódu je struct resource, která sleduje jednotlivé alokace zdrojů. Výpis /proc/iomem nebo /proc/ioports je ve skutečnosti jen jedna z těchto zdrojových datových struktur.
Protože kód pro správu zdrojů napsal Linus na počátku vývojového cyklu verze 2.3, byl pro sledování hodnot zdrojů použit unsigned long. Tehdy to fungovalo, ale na 32bitových strojích, které mají I/O paměťové zdroje na vyšších adresách, to může být problematické. Je-li oblast paměti umístěna mimo 32bitový rozsah, nedokáže se o ni kód pro správu zdrojů postarat.
Řešením je samozřejmě začít pro sledování alokací zdrojů používat 64bitová čísla. Vivek Goyal (společně s dalšími) už nějaký čas pracuje na sadě patchů, která tuto změnu provede. Greg Kroah-Hartman patche opravil a vypadá to, že jsou připraveny k začlenění do 2.6.18.
Zavádění nových typedef do jádra není příliš vítáno, ale tento patch přesto vytváří resource_size_t. Zpočátku je tento typ pouze unsigned long; teprve když se změna projeví v celých zdrojácích, je změněn na 64bitovou hodnotu. Konfigurační volba umožňuje zvolit, jestli mají být použity 64bitové zdroje; kupodivu je 64 bitů nastaveno jako výchozí možnost, kdežto 32 bitů je označeno "experimentální".
V důsledku této změny se mění prototypy některých často používaných funkcí:
struct resource *request_region(resource_size_t start,
resource_size_t n,
const char *name);
void release_region(resource_size_t start, resource_size_t n);
struct resource *request_mem_region(resource_size_t start,
resource_size_t n,
const char *name);
void release_mem_region(resource_size_t start, resource_size_t n);
Většiny kódu ovladačů se změny nedotknou; jednoduché konstantní alokování zdroje bude i nadále fungovat a v mnoha případech se o detaily alokace stejně stará vrstva sběrnice. Ale v případech, při kterých ovladač přímo ukládá nebo pracuje s umístěními zdrojů, bude nutné použít nový typ.
Následující obsah je © KernelTrap
14. čer, originál
Mark Lord hlásil problém s novým jádrem 2.6.17, které si nedokázalo poradit se stránkou www.everymac.com. Podrobně popsal sérii testů, pomocí kterých zjistil, že za tím stojí nedávná sada patchů pojmenovaná nastavení výchozích max bufferů podle velikosti poolu paměti, která dále vysvětluje: Tento patch nastavuje maximální velikosti TCP bufferů (dostupné pro automatické ladění bufferů, ne pro setsockopt) podle velikosti poolu TCP paměti. Maximum pro sndbuf i rcvbuf bude až 4 MB, ale ne více než 1/128 prahu paměťové nouze [memory pressure]. John Heffner vysvětlil, že někde mezi Markovým serverem a webserverem je vadný stroj, který je nutno opravit: Do té doby můžeš problém obejít vypnutím škálování oken.
Linus Torvalds navrhl: No, možná bychom neměli mít výchozí nastavení, které využívá škálování oken, nebo bychom měli mít způsob, jak automaticky rozpoznat, že to nefunguje (což nevím, jestli je možné). Nemůžeme se tvářit, že neexistují nefunkční stroje, a možná by bylo lepší nastavit výchozí velikosti bufferů tak nízké, aby už na škálování oken nezáleželo. David Miller odpověděl s tím, že škálování oken už je jako výchozí nastaveno velmi dlouho, ale doposud se škálovalo jen s koeficientem 1 nebo 2: Naplnit mezikontinentální spojení bez škálování není možné. Velké buffery jsou absolutní nutností a jak ukázal John Heffner, tato nutnost exponenciálně narůstá, neustupuje. 6megabitové stahovací připojení je ve Spojených státech docela běžné, v dobře připojených zemích jako je Jižní Korea je ještě vyšší. Kromě toho vysvětlil, že není možné rozpoznat nefunkční stroje a dynamicky škálování oken vypnout po navázání spojení: Jakmile je povoleno, je aktivní po celou dobu spojení. Škálování oken je standardizováno nějakých 14 let, RFC1323 byl vydán v květnu 1992. Jak dlouho ještě můžeme čekat, než bude korektně nasazováno? :-)
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.