par Gesp » 09 Juin 2008 13:51
Certains couple CF/adaptateur ne supportent pas le DMA.
Il y a aussi dans les CF une RAM qui sert de cache en écriture.
Comme c'est une CF rapide, il est possible qu'elle ait un plus gros cache.
Suivant sa vitesse à écrire les données du cache sur la mémoire flash, possible que le courant soit coupé avant que le cache ne soit vidé. Du coup, certaines transactions du journal ne serait pas enregistrées, ce qui explique l'erreur au démarrage mais pas le fait que débrancher le secteur produise moins d'erreur qu'un arrêt normal. Sauf que l'arrêt normal provoque l'écriture du ramdisk sur la CF, donc il y a beaucoup d'écritures juste avant la coupure du courant.
La solution dans ce cas serait de rajouter un délai dans /etc/rc.d/rc.halt après le lancement de rc.flash.down
Rajoute un sleep 3 pour voir si cela fait une différence.
Je crois que le support du DMA dépend surtout de l'adaptateur IDE<=>CF
Dans ce cas, il faut rajouter ide=nodma sur la ligne du noyau de /boot/grub/grub.conf
Si tu veux tester la fiabilité de ta CF, fait cela en dehors du fonctionnement d'IPCop.
Crée un gros fichier proche de la capacité de la CF
Copie directement le fichier sur la CF avec dd
Pour créer le fichier, tu peux utiliser encore dd et varier le contenu (que des 0 ou un contenu pseudo-alétoire)
Il faut bien sùr que ton système ait suffisament de place de libre pour générer ces fichiers dans /tmp
dd if=/dev/zero /tmp/zero count=2G bs=1000 (un fichier avec que des zero)
dd if=/dev/urandom /tmp/random count=2G bs=1000 (un fichier au contenu aléatoire)
Avec 1000 au lieu de 1024 cela laisse un peu de marge, voire à diminuer encore suivant la capacité annoncée de la CF.
ensuite teste avec chaque fichier en le copiant sur la CF et en le relisant
dd if=/tmp/mongrosfichier of=/dev/hd<x> x étant la lettre correspondant à la CF et pas le disque du système en fonctionnement
Puis relit le fichier par dd
dd if=/dev/hd<x> of=/tmp/mongrosfichier2
Puis
md5sum /tmp/mongrosfichier*
Si les 2 md5 sont identiques, la CF n'a pas créé d'erreur.
Dans le cas contraire, appeler Houston, il y a un pb (sauf si c'est lié au dma comme indiqué plus haut).
Je ne sais pas s'il existe des programmes de test de CF.
Au niveau matériel, c'est un peu différent d'un disque dur.
On ne peut pas effacer individuellement un bloc (par exemple de 512 octets) mais un ensemble de bloc (par ex 32 ko) donc un programme de test de disque dur ne serait peut-être pas très adapté ni badblock.
En plus comme les disques durs modernes, normalement la CF a une réserve de bloc et son controleur effectue de manière transparente le remplacement des mauvais blocs.
Enfin il y a dans certaines CF mais apparament de manière inégale suivant les fabricants un dispositif d'égalisation des effacements :
La CF compte pour chaque ensemble de bloc le nombre d'effacements et égalise le nombre d'effacement sur l'ensemble de la surface. Si certaines données varient souvent, elles ne sont pas réécrites tout le temp au même endroit sur la CF sinon cette partie deviendrait rapidement inmodifiable.
