MacBidouille

Suite à la news de dimanche sur la journalisation, j'ai reçu de trés noimbreuses réponses.
Merci à tous !
En voici certaines (désolé, mais il m'était impossible de toutes les mettre)
De Nicolas

Son problème est classique et ne veut pas dire que la journalisation ne marche pas. Au contraire il constate que ça redémarre plus vite et sans dégâts à son disque, preuve que ça marche.
Par contre, s'il veut s'assurer de l'écriture sur disque de son code, il ferait mieux de faire un sync après sa sauvegarde.
cf. man sync : sync - force completion of pending disk writes (flush cache)
ou alors il attend un peu avant de planter sa machine.
Sous Unix, les écritures sur disques sont toujours différées dans un soucis de rapidité. Le sync force une écriture immédiate.

Le but de la journalisation est d'éviter la moindre corruption du disque dur, pas de garantir que les données sont à jour sur le disque. Il est même connu qu'un des revers de la journalisation (quel quesoit le FS) est que les données sont moins à jour sur le disque.
On peut éventuellement critiquer la fréquence de MAJ sur le disque dur, mais
c'est tout.
En plus de la journalisation, il ne faut pas oublier que MacOS X utilise énormément la mémoire vive en guise de disque cache pour améliorer les performances. Plus une machine est bourrée d'un point de vue mémoire, plus il y a d'informations stockées en mémoire.

a lire la news de ce matin je pense qu'il est bon de rapeler ce qu'est la
journalisation :
sur un system de journalisation, quand on sauve un fichier, il n'est pas ecrit a l'emplacement dans l'ancien fichier, mais dans un emplacement
temporaire (le journal..) puis une fois l'ecriture fini la modification estrepercuté sur le vrai fichier, en cas de coupure de courant, on se retrouve donc les fichiers dans leur version d'avant le crash (apres il a quelque divergence selon les systemes de journalisation) et nom avec des fichier a
moitié ecrit.
donc dans le cas de Pierre Olivier Latou, la repercution sur le vrai fichier n'avais pas encore eu lieu, donc il a eu les anciennes versions des fichiers, c'est normal..

Je pense que son problème de pertes de données lors d'un crash est la preuve que le journaling marche !!
Je m'explique : tant que le journal n'a pas été mis a jour sur le disque les données ne sont pas censées être valides. Donc le fsck considère que
rien n'a été changé pour les fichiers n'aparaissant pas encore dans le journal d'ou la perte des modifications.
On observe le même phénomène sur le système de fichiers de SGI, le XFS.SGI ayant considéré que ses serveurs plantent presque jamais les données
ne sont flushées que très rarement sur le disque et c'est d'autant plusvrai que la machine est bourrée de mémoire, alors utilisée en cache disque.
Sous tout système unix dont macosx il suffit de taper la commande syncpour forcer l'écriture sur le disque, dont le journal !

Il faut toujours et TRES souvent faire un 'sync' avant de loader (ou unloader) une kext. 'sync' sous shell flushe les changements apportes aux disques
immediatement (pas seulement les datas, la structure aussi)'sync' est une commande qui deviens compulsive pour tout developeurs kernel.
Je fais du developement de kext depuis plusieurs mois sous jaguar, et a part quelques problemes tres mineur (le seul fichier 'a risque' quand tu sync le
disque, c'est /var/log/system.log !) je n'ai jamais eut la moindre grosse panne. Et bon, des panics, j'en ais eut des centaines ;-)
Note que si ton driver n'est pas stable, il faut continuer a faire 'sync' regulierement, specialement si tu SAIS que tu vas planter ton driver.
Fichier inclu sont les alias que j'utilise pour faire cycle load/debug/unload.
Ca copie aussi les symboles de debug sur mon autre mac, pour faire de debugging remote quand la premiere est dans les choux :-)
Note que 'sync' y est proheminent :-)