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 les responsables.

Qui êtes-vous ?
Votre message

Pour créer des paragraphes, laissez simplement des lignes vides.
Attention ! Si votre message contient un lien, il devra être validé par le webmestre. Inutile de le poster à nouveau ;-)

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

À la Commission de développement de l’informatique du Ministère des Finances
Bonjour, Sur Noël Aucagne, je vous recommande ceci : https://www.afsp.info/archives/congres/congres

Premiers programmes en Rust
Bonjour, Si vous saviez comme vos messages me font plaisir !! J’ai enseigné et pratiqué (…)

Une sacrée envie de foutre le bordel
D’accord avec le commentaire précédent... très élogieux comme portrait, qui passe un peu vite (…)

Programmation de droite à gauche et vice-versa
Bonsoir, Plongé dans ma biblio de l’histoire des méthodes, je suis allé faire un tour à la bib (…)

Prospérité, puissance et pauvreté : pourquoi certains pays réussissent mieux que d’autres
Bonjour Frédéric, merci de ce message. Alors, Acemoğlu et Robinson ne disent pas explicitement (…)