En r�ponse � Rosaire AMORE <[EMAIL PROTECTED]>:
> Je ne suis pas en production (mon serveur du moins), mais chez moi, �a
> tourne
> depuis que la 7.2 est sortie (un an?). Et je vous garantis que c'est
> parfois
> pire que la production, chez moi (avec les gamins + les copains des
> gamins qui
> connaissent mieux le bouton "reset" que "ctrl-alt-supp" pour rebooter
> sur win$
> pour les jeux! - quand je ne suis pas l�, �videment!) : je confirme, �a
> a
> l'air costaud.
Petit parall�le avec les bases de donn�es au sujet du principe de journalisation.
Le probl�me principal en base de donn�es est que les ordres d'�critures doivent
parfois etre diff�r�s s'ils ont lieu dans une transaction. En effet, si par exemple
vous
faites un virement financier il y a 2 ordres d'�critures :
1) D�bit du compte du d�biteur
2) Cr�dit du compte du cr�diteur
La premi�re �criture doit �tre diff�r�e, puisque si jamais la 2nde op�ration se passe
mal (mauvais no de compte par exemple, ou probl�me software, deadlock ...) vous
aurez fait disparaitre de l'argent !
C'est pourquoi les ordres d'�criture sont stock� dans un journal (log), et les
op�rations inscrites dans le journal sont valid�es en fin de transaction.
Dans le cas d'un filesyst�me, le probl�me est celui du cache (et aussi dans les
bases de donn�es d'ailleurs). Les �critures ne sont pas faites directement sur le
disque, mais d'abord dans le cache, et ce pour des probl�mes de performances.
On utilise donc un "log" ou "journal" qui est une zone o� les op�rations sont �crites
s�quentiellement (donc �a va tr�s vite), et � intervalles r�guliers (on parle de
"checkpoints") les ordres inscrits dans le log seront appliqu�s en "r�al".
Enfin, sachez que pour un filesystem aussi la notion de transaction peut apparaitre,
par exemple si vous ajoutez un bloc de donn�e � un fichier, il y a �galement 2
ordres d'�critures (ou plus) qui devraient �tre indissociables :
1) Ecriture du bloc
2) Mise � jour du descripteur de fichier (pour ajouter l'adresse de ce block)
3) Mise � jour de la liste des blocs disponibles sur le disque
....
Donc quand la gamin appuie sur le bouton reset, que se passe-t-il ?
Dans un filesystem classique, un fsck sera lanc�. Il va parcourir la liste des
descripteurs de fichiers et de r�pertoires, v�rifier que la taille du fichier
correspond
bien au nombre de blocs allou�s, reconstituer la liste des blocs disponibles etc.
Evidemment, si vous avez pas de bol (reset effectue en pleins milieux d'�critures sur
le disque dur), il y aura des fichiers perdus.
Dans le cas d'un syst�me journalis�, l'�quivalent du fsck va consulter le log. S'il
constate qu'il y reste des op�rations, c'est que le shutdown n'avait pas �t� effectu�.
Il va donc tout simplement lire le journal des op�rations et il va les appliquer les
unes derri�res les autres sur le disque (ou la database c'est pareil).
Ce syst�me explique qu'un syst�me journalis� est en g�n�ral un peu plus lent en
�criture qu'un syst�me non journalis� (�critures dans le log).
--
H.Lefebvre [EMAIL PROTECTED]
LINUX : Ne jetez plus votre argent par les fen�tres !
