Portál AbcLinuxu, 27. dubna 2024 23:45
Nový nástroj blktool nahrazující hdparm. Doplnění dokumentace ext3. Rozšíření možností při připojování VFS. Linux 2.6.8.1-mm2; obsahuje Reiser4. Vyhazování #include z 2.6; stabilita není největší prioritou.
15. srp - 19. srp
Jeff Garzik napsal:
Právě jsem dal "blktool" na svoji SF stránku: http://sourceforge.net/projects/gkernel/. V BitKeeperu je v bk://gkernel.bkbits.net/blktool.
blktool se snaží být snadněji použitelnou a více obecnou verzí již existující utility 'hdparm'. Například:
$ hdparm -c1 /dev/hda
bude
$ blktool /dev/hda pio-data 32-bit
a
$ hdparm -L0 /dev/hda
bude
$ blktool /dev/hda media unlock
Nástroj je zatím dost zaměřený na IDE zařízení (stejně jako hdparm), ale to by se v nadcházejících týdnech mělo změnit, protože bude přidáno ovládání SCSI, I2O a možná hardwarového RAID.
Uživatelská obec této aplikace je, podobně jako u hdparm, poměrně malá. Omezuje se na lidi, kteří ladí svá úložná zařízení a _vědí, co dělají_. Stejně jako u hdparm může nesprávné použití tohoto nástroje udělat z vašeho disku zarážku na dveře.
Alanu Coxovi se nelíbil formát parametrů: Takže jsi nahradil podivný, avšak unixovský, formát parametrů hdparm ještě dementnějším, nelinuxovým formátem, který neumí regulární výrazy pro názvy disků? Alan navrhl formát '--parametr=hodnota'. Jeff odpověděl, že upřednostňuje svůj původní mechanismus, protože má podle něj lepší strukturu. Zvláště když počet potenciálních příkazů roste. Ale doplnil, že může implementovat i Alanův návrh.
Vypadalo to, že lidem se Jeffův přístup líbí a začali na tom pracovat.
17. srp - 19. srp
Diego Calleja napsal: Dost lidí si myslí, že ext3 je velmi pomalý. Sice netvrdím, že ext3 je ten nejrychlejší filesystém na světě, ale řekl jsem několika lidem, aby se před hodnocením rychlosti podívali do Documentation/filesystem/ext3.txt a zkusili ext3 lépe nastavit. K mému překvapení není několik ext3 parametrů vůbec dokumentováno (ani ve zdrojovém kódu) - kromě na pár stránkách na internetu. Takže se ani nedivím, že mnoho lidí při testování výkonu ignoruje některé parametry pro mount. Například interval zápisu [commit interval].
Poslal patch pro dokumentaci, ke kterému řekl: Přidává dokumentaci ke commit, seskupí parametry týkající se žurnálu na jedno místo v dokumentu a ještě bez popisu doplňuje další parametry pro mount (například k acl, xattr, změnám velikosti, rezervacím, bariérám). Několik lidí navrhlo zařazení dalších údajů. Diego je sesbíral a převedl na novou verzi dokumentu.
18. srp - 20. srp
Herbert Poetzl napsal: Následující patch umožňuje využití parametrů 'noatime', 'nodiratime' a v neposlední řadě 'ro' (read only) při připojování pomocí vfs --bind. Tím pádem se mohou chovat jako jakýkoliv jiný připojený oddíl, protože ty přepínače berou v potaz (současné implementace v 2.4.x a 2.6.x je tiše ignorují).. Několik lidí projevilo zájem, aby se patch dostal do hlavního jádra; ale Christoph Hellwig řekl, že patch má problémy se svým rozhraním a ve stávající podobě nemůže být přijat. Potvrdil, že funkce je to dobrá; a že ji v hlavním jádře očekává do jednoho roku; i když možná ne v rámci 2.6.
19. srp - 25. srp
Andrew Morton oznámil kernel 2.6.8.1-mm2:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.8.1/2.6.8.1-mm2/
Přidal jsem souborový systém reiser4. Otestujte, prosím. Zprávy o problémech adresujte i na reiserfs-dev@namesys.com. (Při kompilaci na 64 bitových strojích vyplivne nějaká varování - to bude opraveno.)
Tady je krátký dotazník, který pro mě vyplnil Hans, aby se vám s tím lépe začínalo:
Opravdu rychlý návod pro zprovoznění souborového systému.
Reiser4 je filesystém založený na algoritmech tančících stromů [dancing tree algorithms]. Popsaný je na http://www.namesys.com. Mělo by se vám podařit jej začít používat jako kterýkoliv jiný souborový systém podporovaný v Linuxu. Můžete nastavit kompilaci jako modul nebo vestavěný. Reiser4 filesystém vytvoříte pomocí mkfs.reiser4, pak jen připojíte a používáte. Podrobnější informace najdete v http://thebsh. namesys.com/snapshots/LATEST/READ.ME.
Přímá adresa, kterou mohou lidi použít pro získání nástroje mkfs. Také fsck a jakékoliv další.
Uživatelské nástroje pro Reiser4 naleznete na ftp://ftp.namesys.com/pub/ reiser4progs. ftp://ftp.namesys.com/ pub/reiser4progs/README obsahuje podrobné informace o kompilaci a instalaci těchto nástrojů. Všechny reiser4 programy mají také manuálové stránky.
Známé problémy, nedotaženosti atd.
Reiser4 byl zatím testován pouze na i386. Není hotová podpora kvót. Ale brzy by měla. Reiser4 byl rozsáhle testován a dostali jsme se k bodu, kdy lidé v konferenci už nenacházeli žádné chyby. Když jsme to ale řekli ostatním, začalo reiser4 používat o řád více uživatelů a ti nalezli chyby, na kterých teď pracujeme.
Je funkční pouze úplný základ. Exotické pluginy, API pro transakce s více operacemi a přístup k více malým souborům v jednom systémovém volání, komprimace, dědičnost - všechno bylo odloženo na dobu po vydání hlavních funkcí. Komprimační plugin by potřeboval revizi kódu před tím, než jej někdo začne používat.
Prohlášení o kompatibilitě s reiserfs3.
Chcete-li upgradovat z V3 na V4, použijte tar nebo nás zasponzorujte, abychom napsali convertfs.
Měj na paměti, že lidi ten filesystém začnou okamžitě testovat na výkonnost a první dojem přetrvává. Teď máš šanci dát k dobru návod na vyladění, parametry pro mount nebo cokoliv jiného, co bys chtěl, aby lidi pochopili PŘEDTÍM, než začnou s vydáváním výsledků testů.
Reiser4 tím není vyladěný pro fsync/sync/O_SYNC výkon.
Uvidíte-li výsledky výrazně odlišné od těch na www.namesys.com/benchmarks.html, dejte nám vědět. Všimnete-li si charakteristik výkonu, které nebudou tak docela dávat smysl, pošlete email na reiserfs-list@namesys.com. Takové věci nás vždycky zajímají.
Vezměte také při testech v úvahu, jak šetří místem.
Ryan Cumming se pohoršil nad tónem textu nápovědy k ReiserFS. Citoval: "ReiserFS V3 je nejstabilnější linuxový souborový systém, V4 je nejrychlejší. Co se týče tvrzení, že ext2 je na Linuxu de facto standardním filesystémem, nejslušnější, co se k tomu dá říci je, že mnoho lidí by nesouhlasilo. A je zajímavé, že mezi těmi, kteří nesouhlasí, jsou distribuce, jejichž tržní podíl roste. Viz http://www.namesys.com/benchmarks.html, kde najdete důvody, proč by mnozí nesouhlasili."
Ryan k tomu řekl: Taková prohlášení jsou přinejmenším provokativní. Navíc je to zbytečná vata v již tak obsáhlém textu nápovědy. Vypadá to, že by si to zasloužilo trochu editorské práce. Chris Wedgwood odpověděl, že to je prostě 'Hans-speak' (Hansův styl), a že ti, kterým se nelíbí, to mají ignorovat.
19. srp - 25. srp
Dave Jones napsal:
Všiml jsem si, že každý soubor, který je možné zkompilovat jako modul, natahuje sched.h (a tím pádem i všechny další include soubory pod sluncem).
Tento patch
Neprováděl jsem žádná měření, jestli se to projeví při kompilaci, protože očekávám, že se to stejně většinou ztratí v okolním šumu (i když naposledy jsem to dělal někdy počátkem 2.5 a srazilo to skoro minutu). Ale když trochu porozmotáme include špagety, aspoň bude gcc používat při kompilaci méně paměti.
William Lee Irwin III poznamenal: sched.h je tak nechutný odpadkový koš hlavičkových souborů, že by mi nevadilo, kdyby se celé úplně roztrhalo. Každé malé oříznutí je dobré =). O několik dní později si sám odpověděl:
Tímto vyhlašuji loveckou sezónu a hon na linux/sched.h!
V rámci přípravy na přesun všech uživatelských kousků ze sched.h a kvůli znásilnění linux/user.h pro tento účel, převádí tento patch všechna začlenění linux/user.h na asm/user.h
Tim Schmielau se do toho pustil a poslal obrovský patch:
OK, jdeme na to! 
Schválně jak často můžeme ty include vyřadit. Abych začal načisto, podíval jsem se nejprve na vanilla 2.6.8.1 před aplikováním tvých patchů.
Rozbor byl jen na i386; můj osobní config se zkompiluje, allyesconfig ne (což se nepodaří ani s neopatchovaným jádrem).
Během zbytku vlákna neprobíhala žádná velká diskuze. William poslal
několik dalších patchů, všechny poměrně dost závažné. Tim pak
prohodil: Odložil jsem svou práci z pozdního
2.5 na 2.7, ale s novým vývojovým modelem to vypadá, že po nás chtějí,
abychom 2.6 spíš destabilizovali .
V originálu Kernel Traffic 275 vyšla navíc ještě tato témata:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.