Kernel Traffic #296 For 12 Feb 2005

Po menším úklidu najednou df ukázal zajímavé výsledky:

Filesystem        Size  Used  Avail   Use%  Mounted on
/dev/md4         1019M  -64Z   1.1G   101%   /tmp

Filesystem    1K-blocks         Used            Available  Use%  Mounted on
/dev/md4       1043168   -73786976294838127736   1068904   101%   /tmp

Bylo to na souborovém systému ext3 s jádrem 2.6.10-ac10.

Sloupec Used [použito] je celkové mínus volné, takže volné bylo 2^66 + 964440. To 2^66 určitě vzniklo při výpočtu s 4K bloky a dostalo se tam tak, že někde bylo záporné číslo považováno za neoznačené.

Ale mít available=1068904 [dostupné] větší než free=964440 [volné], to je divné.

Předpokládám, že to má na svědomí statfs nebo statfs64. Pomocí "strace -e statfs64 df /dev/md4" můžeš ověřit, jestli jsou to skutečně hodnoty vracené jádrem - abychom mohli vinu rozdělit mezi df a jádro.

Hodnoty se počítají takto

buf->f_blocks = es->s_blocks_count - overhead;
buf->f_bfree = ext3_count_free_blocks (sb);
buf->f_bavail = buf->f_bfree - es->s_r_blocks_count;

tedy: bloky = celkem - režie, a dostupné = volné - rezervované. strace ukazuje tři hodnoty a předpokládám, že tune2fs bude ukazovat 2 nebo více.

Více dostupné než volné zní jako záporný počet rezervovaných bloků. Můžeš tu situaci ještě zkoumat?

Nějaké informace přeci jen mám. Spustil jsem na filesystému e2fsck a bylo to také zajímavé:

/dev/md4: clean, 16/132480 files, -15514/264960 blocks

Když jsem e2fsck přinutil proběhnout, odhalil několik skupin s nesprávnými počtu bloků:

Free blocks count wrong for group #2 (34308, counted=32306).
Free blocks count wrong for group #6 (45805, counted=32306).
Free blocks count wrong for group #8 (14741, counted=2354).
Free blocks count wrong (280474, counted=252586).

Když se tohle opravilo, vrátilo se vše do normálu. Nechal jsem proběhnout dump2fs, takže pokud by to bylo zajímavé, mohu poslat.

Protože metoda uložit [store] nemá offsetový parametr, musí předpokládat, že všechny zápisy jsou od počátku bufferu.

Takže pokud tvůj sysfs soubor obsahuje "123" a ty provedeš

echo "45" >> můjsysfssoubor

tak na místo očekávaného "12345" budeš v souboru mít "45". Otevírání souboru, vyhledávání a zapisování je stejné - opět bez nějakých hlášených chyb.

Tento patch jen nastavuje několik parametrů, které zajišťují, aby byly při takovém chování vraceny chyby. Takže logicky dělají ty dvě "funkce" totéž (nastavují parametry) a zabraňují takovému chování (zapisování špatného obsahu bez chybového hlášení).

Přikládám nové vydání mého návrhu na čas dne, které zahrnuje podporu ppc64 a také háčky pro uspání/probuzení a cpufreq. Základní shrnutí mého návrhu naleznete zde: http://lwn.net/Articles/100665/

Patch implementuje tu část subsystému času dne, která je nezávislá na architektuře. Součástí je timeofday.c (který obsahuje všechny funkce správy a přístupu), ntp.c (který obsahuje škálovací ntp kód, zpracování přechodné sekundy a strojový kód stavu ntp jádra), timesource.c (pro funkce správy zdroje času), hlavičkové soubory definující rozhraní, příklad zdroje času pro "jiffies" a malé háčky do kódu nezávislého na architekturách.

Patch nefunguje bez menších háčků zvlášť pro každou architekturu (budou následovat příklady pro i386, x86-64 a ppc64) a může být na strom aplikován, aniž by nějak ovlivnil kód.

SoftwareSuspend 2.1.5.7B pro jádro 2.4.28 je k dispozici z softwaresuspend.berlios.de.

Nepočítaje opravy chyb a portování na 2.4.29 a pozdější jádra by tohle mělo být poslední vydání SoftwareSuspend pro jadernou řadu 2.4.

2.4 verze Suspend je obecně jednoduchá na zprovoznění, ale pokud máte nějaké otázky nebo problémy, najdete hodně informací na softwaresuspend.berlios.de. Konkrétně HOWTO, FAQ a Wiki, na které se můžete podívat před pokládáním dotazu do konferencí (které tam také najdete).

Kompletnější instrukce ohledně instalace balíku jsou v přiloženém souboru README.