Jaderné noviny 173

9. 7. 2002 | Leoš Literák | Jaderné noviny | 3956×

Škálovatelnost ext2/ext3, čištění jádra a zkracování ext2 a ext3 adresářů.

Do konference přišlo 1159 emailů od 375 vývojářů, nejčastěji psalioli Linus Torvalds, Dave Jones a Ingo Molnar.

Zkracování ext2 a ext3 adresářů, 39 emailů

Někdo připomenul odvěký problém, že po smazání souborů a adresářů z některého adresáře se alokované bloky neuvolní. Odesílatel znal, že řešením je vytvořit nový adresář, zkopírovat do něj obsah starého adresáře, smazat jej a přejmenovat nový adresář. Toto se mu však zdálo ošklivé a tak se zeptal, zda existuje jiný způsob, jak zkrátit [shrink] adresář. Andreas Dilger odpověděl, že takováto vlastnost by vyžadovala spoustu práce, nicméně Stephen C. Tweedie napsal, že Daniel Phillips plánuje začlenění HTree pro rychlou indexaci adresářů pro ext2/3.

Alexander Viro měl za to, že limitovaná verze zkracování by neměla být složitá a hned načrtl způsob, jak na to a nabídl se, že ji napíše, což původní odesílatele velmi potěšilo. Stephen však našel pár slabších míst tohoto návrhu. Andrew Morton se vložil do diskuse s tím, že právě vložil podporu pro HTree pro ext3 do jádra 2.5.23. Diskuse pak pokračovala nad technickými detaily implementace.

Čištění jádra, 6 emailů

H. Peter Anvin napsal, že ten, kdo vytvořil adresář CPU (dobrý nápad) a porušil [break up] arch/i386/kernel/setup.c, udělal ještě jednu chybu: příznaky CPUID definované AMD (0x80000001) nejsou používany jen na AMD procesorech! Ve skutečnosti je používají i Transmeta, Cyrix a Via. Intel je podporuje také, nicméně vrací 0. Podle něj by to mělo být přesunuto do funkce generic_identify(). Dave Jones označil za autora Patricka Mochela a zároveň vyjádřil podporu pro Peterův patch. H. Peter dále dodal, že to samé by se mělo provést se souborem bugs.h. Patrick poděkoval Peterovi za upozornění a pobídl ho k zaslání patche.

Škálovatelnost ext2/ext3, 35 emailů

Lidé z Intelu dělali nějaké testy propustnosti [throughput] blokových I/O operací v závislosti na počtu SCSI adaptérů. Na jejich počítači se dvěma procesory PIII 1.2GHz se 2G RAM a kernel 2.4.16 či 2.4.18 zjistili, že benchmark Bonnie++ ukazuje zpomalení s rostoucím počtem zařízení [spindle]. Podle nich je problém způsoben tím, že ext3 příliš často používá Velký Jaderný Zámek - BKL (Big Kernel Lock). A tak navrhli nahradit BKL zamykáním na úrovni souborového systému. Andrew Morton odpověděl, že škálovatelnost ext3 je bohužel ubohá, neboť neměl čas se jí zabývat. Vývojáři mají plán nahradit lock_kernel zámkem lock_journal, kde ej to možné. Leč škálovatelnost bude adresována pravděpodobně až v řadě 2.5.

Andreas Dilger se zamyslel a poslal několik odstavců návrhů, jak tento problém vyřešit. Andrew také připojil několik svých očekávání, jak na to. Ext2 je jednoduché a bude škálovat až do nebe, leč až v řadě 2.6. Ovšem ext3 je 700x komplexnější než ext2, takže vývojáři musí být opatrní. Stephen C. Tweedie si nemyslel, že je nutné čekat na 2.6 na škálovatelnost ext3. Připomněl, že pouze commit vlákno mění stav transakce, takže lock_journal se může stát read/write zámkem chránícím stavový stroj transakcí [transaction state machine].

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licenci GPL verze 2.

       

Komentáře

[hmm]

Jo, to byli casy kdyz se nezabijeli lidi jen protoze jim nesedi dane pohlavi ale opousteli nas skutecne nemocni lide.

---

Velice se ti ta cenzura vydarila, Kolibaci, skvele zvladnuta moderace a vyuziti vlastniho casu, tleskam komunistickym praktikam. ODBOJ PROTI KOMUNISTUM.