Discussion :

[Seb.26]

Bonjour à tous

et Bonne années 2009 !

Je suis sur un projet Linux embarqué, tout mon système ( kernel, lib, appli ... ) est sur des partitions en lecture seule car comme c'est de l'embarqué, on peut prendre une coupure à tout moment

Mais là, je dois sauvegarder des données !!!

Donc je pensais me faire un petite partition ( j'ai besoin de quelques Mo seulement ) et de la checker à chaque boot.

Puis écrire les données avec un genre de double buffering : je copie le fichier, le modifie, et si tout est OK, je virre l'ancien.

( si vous avez une méthode qui marche, je veux bien aussi ... )

Je me pose maintenant la question de savoir quel type de partition présente le moins de risque, ou encore est le plus facile à réparer en cas de problème ...

Autre question : je me demande si j'ai intérêt à monter ma partition en RW seulement pour les écritures, et ensuite à la remettre en RO ?

Est ce que ça change quelque chose ???

Merci d'avance de vos lumières ...

[bizulk]

Salut !
Je ne suis pas un expert en partition, mais je peux déjà de déconseiller de mettre tes données modifiables sur une même partition que celle ou tu as placée le reste de ton système de fichier, tu risques de rendre ton système inutilisable...
Ensuite tout dépend du type de périphériques que tu vas utiliser pour stocker tes données modifiables, car il faut aussi tenir compte de sa durée de vie.
Si tu veux sécuriser remonter ta partition modifiable en mode RW seulement lorsque tu fais des accès me paraît une bonne idée.

Pour un projet similaire j'avais une flash découpé en deux partitions : la partie non modifiable contenait une image ext2, la seconde du jffs2 (montée sur /var ou /home). Le jffs2 optimisait l'usage de la flash et possède comme son nom l'indique un journal.
Je sais qu'il y a maintenant des nouveaux systèmes de fichiers pour la flash plus performants, à voir dans les options du noyau et les logs des sorties de kernel (qun a un bon lien ?)
Mais comme je l'ai dit plus haut, il faut tenir compte du type de support que tu utilises ?
Sinon j'ai aussi vu cela sur mon asus eeePC : une compact flash avec deux partitions montées en unionfs, la première non modifiable, et toute les modifications des fichiers stockées sur la seconde (complètement transparent pour l'utilisateur). En cas de problème il suffit de formater la seconde partition pour retrouver le système d'origine. L'intégration dans le noyau de l'unionFS était il y a peu sous forme de patch (pb stabilité) mais je n'ai pas de problème avec ...

[Seb.26]

OK, merci de ta réponse

En effet, je compte bien dédier une partition à ces données, le reste restera RO tout le temps !

Pour le support, tu fais bien de le demander, j'avais zappé, c'est bien un DOM ( un flash disk IDE ) qui sera utilisé ...

Je vais regarder ce que c'est que le "jffs2" ...

Pour être un peu plus précis, sur mon système : je vais mettre environ 16Mo de DATA ( RW ) ... est-ce que la taille de la partition a une influence sur les risques ?
( car je peux aussi repartir les données sur plusieurs partitions si besoin )

Ou encore faire une partition "/DATA", et une autre "/SAVE_DATA" ... avant chaque modif dans DATA, je duplique son contenu dans SAVE_DATA ... puis en fin de modif je remonte DATA en RO si tout est OK, puis je vide SAVE_DATA ...

De cette façon, si au boot DATA est corompu, je restore l'ancienne version avec le contenu de SAVE_DATA ( tant pis pour l'info perdue : c'est pas des données critiques !!! )



Si vous avez d'autres idées lumineuses, n'hésitez pas !

[Seb.26]

PS: il n'y aura qu'un seul fichier sur cette partition, un fichier de log, donc systématiquement utilsé avec du fprintf(...) en "append" ... est-ce que cela pose des problèmes particuliers ??? ( ou au contraire aide )

Car normalement seul le dernier "secteur" de la flash (celui qui est utilisé par la fin du fichier) est à remettre à jour ... jffs2 sait faire cela ou va t'il à chaque fois tout ré-écrire ??? ( je pense qu'il va faire ça intelligemment, mais on sait jamais ! )

Si mes notions sont bonnes, on ne peut que formater / écrire un bloc complet dans une flash ...

[bizulk]

Bonjour,
JFFS2 est dédié à disque type flash et optimisé pour allongé leur durée de vie. Si tu modifies un fichier, tu écriras "toujours" au même endroit et cela peut rendre ta flash inutilisable pour un secteur défectueux. JFFS2 en tient compte et optimise l'usage de ton disque.
Pour ce qui est des facteurs "nombre et taille de partition" je dirais que plus tu en as plus tu as de risque d'avoir des corruptions.
Maintenant pour ce qui est de protéger des données par redondance, mon avis est que c'est complètement inutile à partir du moment ou tu utilises le même support pour copier les données et leurs copies, le mieux dans ce cas est d'utiliser un second disque.

Ou encore faire une partition "/DATA", et une autre "/SAVE_DATA" ... avant chaque modif dans DATA, je duplique son contenu dans SAVE_DATA ... puis en fin de modif je remonte DATA en RO si tout est OK, puis je vide SAVE_DATA ...

Est-tu sur de réellement savoir quelle est la donnée corrompue et la saine ? Quelle méthode de vérification vas-tu utiliser ?

N'oublie pas que tu as souhaité intégrer un outil dans ton FS : un journal.

Je pense qu'il faut d'abord :

• énoncer les scénarios de corruption de FS (ex : coupure de courant lors de l'écriture d'un fichier)
• Si le FS est journalisé vérifier que celui-ci vérifie l'intégrité des fichiers et sa capacité à les restaurer (ex : restaurer le précédent fichier corrompu lors du démarrage).

Ensuite fais un test et ta conclusion.

Si tu souhaites rajouter une méthode pour vérifier l'intégrité des fichiers tu peux par exemple ajouter leur checksum dans un autre fichier et les vérifier au démarrage (avec le risque que celui-ci soit aussi corrompu ). Si l'un deux n'est pas bon tu peux restaurer le fichier à partir d'une image de ta partition placée en lecture seule (en gros une restauration des valeurs par défaut).


Autre chose que je n'ai jamais vu sur ces équipements embarqué et qui pourrait être sympa : le système embarqué pourrait être équipé d'une sorte de pile (une grosse capacité) qui se charge sous tension et lorsqu'elle se décharge par suite d'une coupure de courant l'OS est en avertit et termine proprement ses programmes. Comme cela plus besoin de se casser la tête avec ces problèmes de corruption. Le fait est qu'il est difficile de faire logiciellement face à des problèmes matériels.

[bizulk]

Une alternative à regarder de plus près à JFSS2 : l'UBIFS si tu utilises un noyau récent.
Des liens sérieux sont donnés en référence dans le wikipedia :
http://fr.wikipedia.org/wiki/UBIFS

[Seb.26]

Maintenant pour ce qui est de protéger des données par redondance, mon avis est que c'est complètement inutile à partir du moment ou tu utilises le même support pour copier les données et leurs copies, le mieux dans ce cas est d'utiliser un second disque.

Ah ? ... je pensais que les partitions étaient indépendantes les unes des autres ... ce n'est pas le cas ???
ça voudrait alors dire que mes partitions RO pourraient être aussi corrompes ??!! ... bizarre ce que tu me dis là ...
( l'idée était de dupliquer les fichiers sur 2 partitions )

Autre chose que je n'ai jamais vu sur ces équipements embarqué et qui pourrait être sympa : le système embarqué pourrait être équipé d'une sorte de pile (une grosse capacité) qui se charge sous tension et lorsqu'elle se décharge par suite d'une coupure de courant l'OS est en avertit et termine proprement ses programmes. Comme cela plus besoin de se casser la tête avec ces problèmes de corruption. Le fait est qu'il est difficile de faire logiciellement face à des problèmes matériels.

Oui, je réfléchis aussi à une solution de ce type ... mais c'est pas trivial ... ( et surtout cela a un cout ! )

Une alternative à regarder de plus près à JFSS2 : l'UBIFS si tu utilises un noyau récent.
Des liens sérieux sont donnés en référence dans le wikipedia :
http://fr.wikipedia.org/wiki/UBIFS

Ok, merci : je vais regarder ça aussi alors !

NB: mon kernel est un v2.6.24.7

Merci à vous.
Seb.

PS: le journal du JFSS2 permet t'il par exemple de restaurer la version n-1 d'un fichier en cas de problème ?

Je pensais aussi à utiliser un fichier sur la partition comme flag de corruption :

pseudo-C-code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
void ecrire_fichier( data )
{
  partition_RW()
  supprimer_fichier_flag()
  fwrite( data )
  refaire fichier_flag()
  partition_ro()
}

De cette façon, 2 cas :
> au boot, fichier flag OK : RAS
> au boot, le fichier flag est absent : problème -> check de la partition

vous voyez des failles à mon système ?

[bizulk]

Ah ? ... je pensais que les partitions étaient indépendantes les unes des autres ... ce n'est pas le cas ???
ça voudrait alors dire que mes partitions RO pourraient être aussi corrompes ??!! ... bizarre ce que tu me dis là ...

Je n'ai jamais dit cela, mais il y a plein d'autres manières de flinguer ta flash ou de perturber ses accès ...

sinon pour répondre à ta question sur les possibilités de jffs2 a restaurer un fichier : lis la doc et fais un essai...

[Seb.26]

Je n'ai jamais dit cela, mais il y a plein d'autres manières de flinguer ta flash ou de perturber ses accès ...

OK ... j'ai lu de traviole ...

De toute façon, une partition en RO ne peut pas être corrompue, si ?
( et si oui : donc avec 2 partitions DATA et DATA_SAVE en RW à tour de rôle, je suis sûr d'en avoir "au pire" une seule corrompue, non ? ... )

Merci, @+
Seb.