Lo scorso 23 Settembre con questo messaggio apparso sulla mailing list ufficiale del kernel linux, Linux Torvalds annuncia l'uscita del kernel 2.4.10:
List: linux-kernel
Subject: Linux-2.4.10
From: Linus Torvalds <torvalds@transmeta.com>
Date: 2001-09-23 18:54:13
Ok, I released a real 2.4.10, let the fun begin..
This is an uncomfortably large changeset, largely
because I was away in Finland twice during the
2.4.9->2.4.10 development, and partly of course
because I've tried to aggressively sync up
especially with Alan.
In addition to the VM changes that have gotten so
much attention there are architecture updates,
various major filesystem updates (jffs2 and NTFS),
ACPI updates, and tons of driver merges. And, of
course, the min()/max() changes.
Give it hell,
Linus
Facendo seguire il contenuto del changelog con le maggiori modifiche apportate nelle varie pre (15 in tutto) dal 2.4.9 fino alla 2.4.10.
Le maggiori novità introdotte in questa versione del kernel riguardano la gestione della Virtual Memory (VM) enormemente migliorata. Linus ha accettato di inserire nel kernel le modifiche apportate da Andrea Arcangeli, preferendole a quelle presenti nel kernel patchato da Alan Cox (il kernel ufficiale e quello di Alan Cox utilizzano quindi una diversa gestione della VM). Da molto tempo infatti Linux soffriva di problemi di impaginazione della memoria, dovuti appunto a una cattiva gestione della VM, e i kernel della serie 2.4 sembravano non imbroccarne una giusta in questo senso (tra l'altro i problemi della VM erano stati la causa maggiore del ritardo del rilascio del kernel 2.4.0). Il 2.4.10 rappresenta un grandissimo passo in avanti in questo senso. La gestione della VM è stata completamente riscritta, provocando per questo le critiche di alcuni che vedevano in questo tipo di approccio (meglio continuare a utilizzare la vecchia, cercando a poco a poco di correggere gli errori presenti) una nuova possibile causa di instabilità, ma le prestazioni sembrano dare ragione ad Andrea Arcangeli.
Le reazioni all'interno degli sviluppatori Linux sembrano essere contrastanti. Anche Alan Cox e Rik van Riel (uno dei principali sviluppatori assieme ad Arcangeli della gestione della VM, e tutt'ora autore dell'implementazione per il kernel ac) non sono rimasti entusiasti di questa nuova release.
Quello che ha portato Arcangeli a riscrivere gran parte dell'algoritmo di implementazione della Virtual Memory (pubblicando dapprima la patch 2.4.10-pre10-aa1) è stata la considerazione che un approccio che portava a migliorare gradualmente la presistente gestione non avrebbe dato i frutti sperati. Per questo ha pensato di sostituire gran parte dell'algoritmo, compresa la parte riguardante il page aging. Il page aging è il meccanismo che si occupa di stabilire quali pagine debbano andare in swap e quali rimanere in RAM. Fondamentalmente il suo compito (ed è qui che ci sono stati i maggiori problemi) è quello di cercare di valutare correttamente quali pagine hanno più probabilità di non essere lette per il maggior tempo possibile, in modo da spostare queste ultime in swap (la memoria di swap risiede su disco fisso ed è perciò di gran lunga più lenta della RAM) liberando quindi RAM. Le impressioni degli utenti nei confronti di questa release sono state molto positive: tutti (o quasi) sono rimasti molto soddisfatti delle prestazioni del nuovo kernel, pur constatando una maggiore instabilità.
Il nuovo kernel infatti sembra soffrire particolarmente in determinate condizioni di estremo carico, che porta a generare errori in fase di allocazione del tipo:
__alloc_pages: 0-order allocation failed (gfp=0x1d2/0) from c0129a3e
provvedendo successivamente a "killare" alcuni processi. Ciò è dovuto a una cattiva implementazione nella funziona shrink_caches() nel file /usr/src/linux/mm/vmscan.c, che sembra infatti dare alcuni problemi nel liberare pagine di memoria dalla lista di quelle attive, anche se non più usate. Ciò porta a una conseguente errata valutazione dell'ammontare di pagine libere, con relativo kill di processi (tutto questo è valutabile anche con un banale cat /dev/hda > /dev/null). Una soluzione a questo problema è già stata fornita da Andrea Arcangeli nella sua patch aa-vm-tweaks-2, che introduce anche ulteriori ottimizzazioni.
Come già detto il kernel ufficiale e quello di Alan Cox hanno utilizzato 2 tipi diversi di implementazione della VM, rendendo possibile un confronto tra i due, cosa che, secondo me, permetterà di poter fare dei contronti sul tipo di sviluppo seguito e sulla qualità delle due differenti gestioni.
Altre modifiche degne di nota nel kernel 2.4.10 sono state la correzione del bug che generava un errore di compilazione per il supporto a NTFS, un miglioramento del supporto ad ACPI e alle periferiche USB, al filesystem journaled ReiserFS e il passaggio alla nuova funzione min()/max().
A proposito di ReiserFS c'è da dire che ultimamente il dibattito sui filesystem journaled è molto aperto, anche perchè, soprattutto con le prime release del kernel 2.4, ha dimostrato di aver bisogno ancora di ulteriori test, in quanto veniva riscontrata in alcuni casi la corruzione di alcuni files (ora questi problemi sono stati risolti). Questo deriva dalla struttura stessa di ReiserFS, che effettua il journaling dei soli meta-data, non di tutti i dati, riducendo quindi sensibilmente l'accesso al disco rispetto ad altri tipi di filesystem journaled e aumentando quindi la velocità.
Ed è una notizia abbastanza recente quella che annuncia la decisione di Red Hat di supportare come filesystem journaled ext3, il successore di ext2, che effettua il journaling sia dei meta-data che dei data, risultando quindi molto più stabile e affidabile, seppur a scapito di prestazioni. Vedremo come si evolveranno le cose in proposito. E' anche vero che ReiserFS non era previsto in un primo tempo per il kernel 2.4, ma Linus ha pensato bene di inserirlo cedendo alle richieste di chi insisteva perchè anche Linux fosse alla pari degli altri Unix più blasonati (come AIX di IBM o IRIX di SGI), che adottano già da tempo un tale tipo di filesystem (jfs e xfs rispettivamente). Oltretutto la presenza di un fs journaled è quasi d'obbligo nell'utilizzo di un LVM (Logical Volume Manager), feature anche questa richiesta con insistenza (venne fatta addirittura una petizione per il suo inserimento nel kernel ufficiale).
Senza dilungarmi ulteriormente su argomenti troppo tecnici che potrebbero essere oggetto di una trattazione futura più specifica e approfondita, ricordo che il vantaggio maggiore che si ha con l'utilizzo di un filesystem journaled è la drastica riduzione di rischi di corruzione dei files in seguito a blocchi di sistema o a crash improvvisi, e relativo aumento di velocità del check delle partizioni al boot seguente (praticamente i tempi di attesa sono nulli). Siamo sicuri che la direzione da prendere nello sviluppo di un tipo di filesystem sia questa, solo il tempo poi saprà dirci quale tipologia di implementazione prenderà il sopravvento sulle altre.
Per quel che riguarda la compilazione e l'installazione del nuovo kernel, essa non comporta grossi problemi, basta attenersi alla classiche istruzioni (per maggiori dettagli potete consultare l'articolo: Come ricompilare il Kernel Linux:
1) scaricare la nuova patch o immagine del kernel:
lnxbox1:/usr/src# wget ftp://ftp.kernel.org/[...]/linux-2.4.10.tar.gz
Oppure a seconda se abbiamo già installato i sorgenti del kernel 2.4.9 (a tal proposito ricordo che la patch per il kernel 2.4.10 si può applicare solo sui sorgenti del 2.4.9, che se non avete dovrete provvere ad installare con lo stesso metodo):
lnxbox1:/usr/src# wget ftp://ftp.kernel.org/[...]/patch-2.4.10.bz2
(diamo per scontato di essere loggati come utente root e di essere nella directory /usr/src)
2) patchare il kernel, o installare direttamente la versione completa (linux-2.4.10.tar.gz o linux-2.4.10.tar.bz2). Esempio:
lnxbox1:/usr/src# tar xfvz linux-2.4.10.tar.gz
se non abbiamo nessuna versione dei sorgenti del kernel 2.4.9 già installata.
Disponiamo già i sorgenti decompressi in /usr/src/linux possiamo tranquillamente applicare la patch con:
lnxbox1:/usr/src# bzip2 -dc patch-2.4.10.bz2 | patch -p0
A questo punto potremo procedere alla ricompilazione vera e propria del nostro nuovo kernel. Se abbiamo già ricompilato il kernel e volessimo mantenere la configurazione precendete (prima di compilare il kernel dovremo dare un make mrproper che provvederà, tra le altre cose, a cancellare il nostro file di configurazione) potremo:
3) copiare il file /usr/src/linux/.config in una directory a nostro piacere (per esempio in /root) con:
lnxbox1:/usr/src# cp linux/.config /root
4) spostarci nella directory linux e dare come comando make mrproper:
lnxbox1:/usr/src# cd linux lnxbox1:/usr/src/linux# make mrproper
5) ricopiare il file .config originario nella directory /usr/src/linux:
lnxbox1:/usr/src/linux# cp /root/.config .
6) eseguire make oldconfig
lnxbox1:/usr/src/linux# make oldconfig
7) eseguire make menuconfig, (oppure make config o make xconfig) per ritoccare eventualmenente il nostro file di configurazione e successivamente salvare:
lnxbox1:/usr/src/linux# make menuconfig
8) eseguire make dep, make bzImage, make modules e make modules_install
lnxbox1:/usr/src/linux# make dep && make bzImage && make modules && make modules_install
9) copiare il file appena creato /usr/src/linux/arch/i386/boot/bzImage in /boot/XYZ, sostituendo XYZ con il nome dell'immagine a cui fa riferimento il file lilo.conf con more /etc/lilo.conf (in particolare fate attenzione alla riga contenente image=/boot/XYZ):
lnxbox1:/usr/src/linux# cp arch/i386/boot/bzImage /boot/XYZ
10) eseguire LILO:
lnxbox1:/usr/src/linux# lilo
Per ogni maggiore delucidazione è sempre possibile (nonchè raccomandabile, la prudenza in questi casi non è mai troppa) rileggere l'articolo:Come ricompilare il kernel linux.
A presto e buona compilazione!
