Quelle option de montage utiliser pour le système de fichiers ext3 pour minimiser la perte ou la corruption de données?

J'ai une configuration intégrée utilisant un initramfs pour le système de fichiers racine mais utilisant une partition ext3 personnalisée montée sur un lecteur IDE flash compact. Parce que l'intégrité des données face à la perte de puissance est le facteur le plus important dans toute la configuration, j'ai utilisé les options suivantes pour monter (ci-dessous l'entrée de mon /etc/fstabfichier

<file system> <mount pt> <type> <options>                         <dump><pass>
/dev/sda2     /data      ext3   auto,exec,relatime,sync,barrier=1 0     2

Je suis venu par ces options en lisant sur Internet. Ce qui m'inquiète, c'est que le contenu de /proc/mountsdonne ce qui suit:

/dev/sda2 /data ext3 rw,sync,relatime,errors=continue,user_xattr,acl,
barrier=1,data=writeback 0 0

D'après ce que je comprends en lisant autour, je veux utiliser l' data=journaloption pour ma monture car cela offre la meilleure protection contre la corruption de données. Cependant, à partir de la page de manuel des options ext3 spécifiques, mountil indique ce qui suit à propos de l'option d'écriture différée:

L'ordre des données n'est pas conservé - les données peuvent être écrites dans le système de fichiers principal après que ses métadonnées ont été validées dans le journal.
Selon les rumeurs, il s'agit de l'option à plus haut débit. Il garantit l'intégrité du système de fichiers interne , mais il peut permettre aux anciennes données d'apparaître dans les fichiers après un crash et une récupération de journal.

Je suis très confus à ce sujet - la page de manuel semble suggérer que pour l'intégrité du système de fichiers, je veux spécifier l' data=writebackoption mountmais la plupart des autres références que j'ai trouvées (y compris certains livres publiés sur Linux embarqué) suggèrent que je devrais utiliser data=journal. Quelle serait la meilleure approche à utiliser pour moi? La vitesse d'écriture n'est pas du tout un problème - l'intégrité des données l'est cependant.

Ne vous laissez pas induire en erreur par le fait que ne writebackmentionne que internal filesystem integrity.
Avec ext3, si vous utilisez journal, orderedou writeback, les métadonnées du système de fichiers est toujours tourillonne et que des moyens l' intégrité du système de fichiers interne.

Les modes de données offrent un moyen de contrôler la façon dont les données ordinaires sont écrites dans le système de fichiers.
En writebackmode, les modifications de métadonnées sont d'abord enregistrées dans le journal et un bloc de validation est écrit. Une fois le journal mis à jour, les métadonnées et les écritures de données peuvent continuer. data=writeback peut être un risque de sécurité grave: si le système se bloque lors de l'ajout à un fichier, après la validation des métadonnées (et des blocs de données supplémentaires alloués), mais avant l'écriture des données (blocs de données remplacés par de nouvelles données), puis après le journal récupération ce fichier peut contenir des blocs remplis de données de fichiers précédemment supprimés - de n'importe quel utilisateur ¹ .

Donc, si l'intégrité des données est votre principale préoccupation et que la vitesse n'est pas importante, data=journalc'est la voie à suivre.

Comme vous l'avez déjà remarqué, le point principal est que vous ne pouvez pas empêcher votre système de fichiers de tout type de plantage.

Ce que tu peux faire:

1. Côté logiciel, vous pouvez utiliser fdatawrites après chaque opération importante (Voir ce billet de 2003 de Theodore T'so, un développeur principal du noyau Linux FS. C'est toujours vrai. Il y a aussi celui-ci sur une perte de données majeure cachée dans les anciennes versions d'ext4)
2. Réduisez l'intervalle de validation à 1 seconde ( commit = 1 ) (voir cet article de LWN, il s'agit d'ext4 mais contient des informations vraiment utiles sur ext3). NB: Cela ne devrait pas être nécessaire, avec la synchronisation .
3. Comme l'a dit RHEL doc pointé par sim, utilisez * data_err = abort * et data = commandé
4. noatime réduira les opérations inutiles sur le système de fichiers
5. Comme vous l'avez déjà remarqué, la barrière = 1 est un bon moyen de minimiser la perte de données (voir ce post )
6. Et la synchronisation est également, bien sûr, l'une des options "Je ne veux pas perdre mes données".

À la fin, les options de montage paranoïaque peuvent ressembler à ceci:

auto,exec,relatime,sync,barrier=1,commit=1,data=ordered,data_err=abort,noatime,

Et vous pouvez également garantir l'intégrité des données avec un fsck automatique à chaque démarrage.

Essayez de changer la partie de la page de manuel que vous mettez en valeur:

réécriture

L'ordre des données n'est pas conservé - les données peuvent être écrites dans le système de fichiers principal après que ses métadonnées ont été validées dans le journal. Selon les rumeurs, il s'agit de l'option à plus haut débit. Il garantit l'intégrité du système de fichiers interne, mais il peut permettre aux anciennes données d'apparaître dans les fichiers après un crash et une récupération de journal.

Comme l'a souligné don_crissti, les autres modes n'ont pas le "cependant".