Combien de temps les écritures du système de fichiers peuvent-elles être mises en cache avec ext4?

Il y a quelque temps, il y a eu des discussions sur le fait qu'ext4 pourrait laisser des fichiers vides après un démontage impur, résumé assez bien dans cet article . Fondamentalement, en raison de l'allocation retardée, les écritures peuvent être conservées dans le cache d'écriture pendant une durée beaucoup plus longue que l'intervalle de validation par défaut du journal ext (5 secondes).

Les problèmes semblent avoir été résolus dans un correctif qui force l'allocation de blocs dans certaines situations, forçant ainsi les données sur le disque après au plus 5 secondes par défaut.

Je me demande ce qui se passe lorsqu'une application écrase des parties existantes d'un fichier, sans tronquer ou ajouter le fichier lui-même. Cela sera-t-il également forcé de disque dans les 5 secondes?

Cela semble être une situation différente de l'ajout à un fichier: lors de l'ajout, la taille du fichier change, ce qui est un changement de métadonnées; par conséquent, une validation du journal sera nécessaire dans les 5 secondes, et en raison des données = commandées, les données devront être écrites avant cela pour des raisons de sécurité (sinon des parties des fichiers supprimés d'autres utilisateurs pourraient apparaître pour le propriétaire de la pièce jointe). fichier).

Lorsque vous écrasez simplement les données du fichier, il n'y a aucune raison pour que l'écriture de données doive avoir lieu avant la validation du journal de métadonnées, car les anciennes données appartiennent au même utilisateur que le nouveau. L'écriture a-t-elle donc lieu avant la validation ou peut-elle être retardée plus longtemps que l'intervalle de validation du journal? Si oui, combien de temps?

Mise à jour: je sais que tout cela n'est pas pertinent lorsque l'on fait la bonne chose, c'est-à-dire en utilisant fsync (). (C'était la raison principale de toutes les discussions sur ext4 et la perte de données - le problème ne concernait que les applications non fsync () ing, ou pas au bon moment.) Je n'écris pas ma propre application, je demande parce que je Je ne sais pas si toutes mes applications font la bonne chose, et je veux connaître un délai approximatif pour de telles écritures "dangereuses". La raison de cette question est que mon pilote graphique provoque régulièrement des paniques du noyau, et je veux savoir si je dois m'inquiéter de plus que les 5 dernières secondes d'écriture de données.

Vous pouvez définir l'intervalle de validation sur une valeur personnalisée qui, je crois, peut être aussi élevée qu'un nombre entier non signé de 32 bits de secondes; donc environ 4 milliards de secondes, soit 136 ans. Ceci est disponible via l' commitoption de montage, que vous pouvez appliquer comme suit (ce n'est qu'un exemple; vous pouvez également le définir dansfstab ):

mount /dev/sda1 -t ext4 -o rw,data=writeback,nobh,commit=12345678

L'intervalle de validation n'est basé sur aucun type de condition, par exemple si les données sont ajoutées ou écrasent les données existantes ou autre. lecommit option de montage (qui par défaut est de 5 secondes si vous ne fournissez pas du tout l'option de montage) équivaut à faire quelque chose comme ça dans un shell bash:

#!/bin/bash
while :
do
    echo "Syncing all uncommitted data and journal to disk"
    sync
    sleep 5
done

Ne confondez pas data=orderedet cet intervalle de synchronisation global du système de fichiers ("intervalle de validation" est peut-être un terme moins significatif pour ceux d'entre nous qui comprennent la fonctionnalité du programme de ligne de commande sync, auquel cas il pourrait être mieux nommé "intervalle de synchronisation"). data=orderedconcerne l' ordre dans lequel les données et les métadonnées sont mises à jour (où data=writebackest "moins sûr / plus rapide" et data=journal"plus sûr / plus lent"). commit=12345678concerne la fréquence à laquelle le pilote du système de fichiers lui-même force une synchronisation COMPLÈTE de TOUTES les données / journaux / métadonnées sales / quoi que ce soit sur le support physique. Et vous pouvez très certainement le régler à 136 ans si vous le souhaitez, et monter avec data=writeback,nobhet des programmes qui n'appellent pasfsync() ou sync()auront des pages sales assis dans la RAM pendant ...

Mise à jour: En fonction de votre contexte dans la modification de votre question, je dirais que vous devez exécuter votre système de fichiers avec des options de montage data=journal,commit=1ou même avec l' syncoption de montage, jusqu'à ce que vous soyez en mesure de résoudre les paniques du noyau de votre pilote graphique. Cela permettra de maintenir une intégrité maximale des données, mais au détriment des performances. Vous voudrez particulièrement le faire si vous écrivez fréquemment des données sur le disque que vous ne pouvez pas vous permettre de perdre, et c'est doublement important si vous ne "faites pas confiance" aux applications que vous utilisez pour utiliserfsync() correctement.

Source: ici et expérience personnelle

Quelle que soit la réponse à votre question, cela n'a pas d'importance.

Le comportement exposé garanti du système de fichiers ext4 est que "les données seront sur le disque après un appel sync/ succès fsync". Donc, si vous avez une application qui vous fait poser cette question, vous devez insérer des appels de synchronisation aux points critiques où l'intégrité des données doit être assurée. Si vous êtes un utilisateur préoccupé par le même problème, vous pouvez appeler l' syncutilitaire de ligne de commande avant de faire tout comportement dangereux susceptible de provoquer un arrêt impur.