Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

Forum de l’article

Mémoire virtuelle, persistance : faut-il des fichiers ?

modération a priori

Ce forum est modéré a priori : votre contribution n’apparaîtra qu’après avoir été validée par un administrateur du site.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.

Lien hypertexte

(Si votre message se réfère à un article publié sur le Web, ou à une page fournissant plus d’informations, vous pouvez indiquer ci-après le titre de la page et son adresse.)

Rappel de la discussion
Mémoire virtuelle, persistance : faut-il des fichiers ?
Robert Ehrlich - le 25 mars 2014

Je déterre un peu ce sujet pour quelques remarques sur les systèmes de fichiers journalisés, que je voulais faire tout de suite, mais d’autres occupations ...
I l y a une chose que je n’ai jamais comprise dans ces systèmes journalisés : comment peut-on assurer de revenir à l’état avant ou après transaction sans sauver dans le journal l’un de ces deux états, ce qui fait doubler les opérations d’écriture, donc divise par 2 (ou plus par mise en défaut des optimisations positionnelles) le débit en écriture ?

Une alternative qui me semble préférable et dont on entend peu parler est celle développée par McKusick et son équipe pour le système de fichiers FFS de BSD baptisée "soft update", encore appelée "ordered write", qui consiste à ordonner les écritures de façon à ce que le système de fichiers reste à tout moment dans un éat cohérent, si ce n’est peut être une incohérence entre la description de l’espace libre et ce qui l’est réellement, toujours dans le sens sans danger (ce qui est occupé n’est jamais décrit comme libre, le contraire peut arriver). On perd là aussi un peu en débit puisque l’ordre imposé empêche parfois de réordonner pour faire de l’optimisation positionnelle, et aussi de retarder une écriture en espérant que la copie mémoire du bloc modifié le sera à nouveau prochainement, ce qui regroupe pluieurs écriture en une seule (ce n’est pas interdit, mais les dépendances d’ordre peuvent forcer une écriture parce qu’on a par ailleurs décidé d’en effectuer une autre, qu’on n’aurait pas faite sans cette dépendance), mais on ne rajoute pas d’écriture, et il n’y a pas de journal à rejouer après un crash, il faut seulement faire tourner une version simplifiée de fsck en arrière-plan pour éventuellement récupérer l’espace perdu.

Derniers commentaires

Une illustration de la concurrence monopolistique
Attention : les GPU sont très forts en produits scalaires, (en multiplication de matrices par (...)

Python
"on dit plutôt maintenant développeurs" ... Il y a (au moins) deux expressions qui (...)

À la Commission de développement de l’informatique du Ministère des Finances
Article tout aussi instructif que plaisant à lire. On pensera aussi à "Comédies Françaises", (...)

À la Commission de développement de l’informatique du Ministère des Finances
Dans le style qui t’est caractéristique, j’avoue que j’ai bien aimé ! J’ai même eu l’occasion (...)

Informatique confidentielle
La clé pour comprendre est peut-être qu’il s’agit ici de "machine virtuelle" et non de (...)