XigmaNAS

Bonjour,

J'avance toujours dans ma réflexion pour passer au zfs sur mon nas.

Je me pose la réflexion suivante: si la carte mère ne supporte pas plus de 8 Go de RAM, cela signifie t il qu on ne peut pas avoir plus de 8 To de stockage (j ai lu qu il faut 1 Go de ram par To) ?

Je sais que 8 To c'est énorme, mais c'est pour savoir qu'elles sont les alternatives pour élargir la RAM quand physiquement on ne peut plus.

Merci

J'ai longtemps utilisé une carte à base d'atom (D525) qui ne supportait officiellement 4 Go de ram avec 6 disques de 2 Tera et ça fonctionnait très bien.
1 g de ram par To de stockage est une recommandation, pas une obligation sauf si vous avez de multiples utilisateurs qui se connectent simultanément.

Merci.

Sur cette carte à base d'atom, aviez vous de la mémoire ECC ? Sur votre carte actuelle, est ce aussi de la mémoire ecc ?

Quel type de mémoire ecc faut il ? unbuffered ? buffered ? ou registered ?

Je pose ces questions car aujourd'hui j'ai de la DDR2 standard non ecc et passer à l'ecc à un cout non négligeable et c'est rare pour trouver de l'ecc en DDR2.

Merci par avance.

Non pas d'ecc, ce n'est pas une obligation mais une sécurité.

Une sécurité pour quel type de données ?

Sur le zfs je vais stocker des données sources (photos, musiques,...) et il y aura des services installés (owncloud, serviio,...).

Est ce que la mémoire ecc sécurise le fonctionnement des services ? ou est ce aussi la sécurité des données sources ?

Toutes les données passent à un moment par la mémoire vive, et c'est valable pour tous les systèmes de fichiers.
Si l'on insiste sur la mémoire ECC pour ZFS c'est pour souligner la robustesse de ce système car s'il peut résister à tous les problèmes de disques et même au coupures d'alimentation, il demeure tributaire des erreurs mémoire.
Si un "condo" flanche dans une mémoire, il se peut par exemple qu'un 8 deviennent un 7 et aucun système de fichiers ne peut voir cela, il considèrera la valeur 7 comme valide.
Pire même, si l'on fait une sauvegarde elle est également entachée de la même erreur.

"Est ce que la mémoire ecc sécurise le fonctionnement des services ? ou est ce aussi la sécurité des données sources ?"

Considérez que la mémoire vive est celle de votre cerveau et que le système de fichiers est un livre : que pouvez vous faire d'un livre si votre cerveau est défaillant ?

"Quel type de mémoire ecc faut il ? unbuffered ? buffered ? ou registered ?"

C'est la carte mère qui impose le choix de mémoire, mais je ne vais pas rentrer dans les détails car votre carte mère ne supporte pas la mémoire ECC.

Rassurez-vous quand même les erreurs mémoires sont tout de même assez rares.

Bonjour

Merci c est très claire.

Ma carte mère supporte certaines mémoires ecc selon la liste des mémoires sur le site de asus. Mais je vais m en passer car les compatibles sont difficiles a trouver.

Bon week end

je parlais de la carte MSI A78M-E35, pas de la P5W.

Autant pour moi

sleid wrote:je parlais de la carte MSI A78M-E35, pas de la P5W.

bonjour,
vous parler bien de la carte mère A78M-E35 ? ,si oui ...alors moi je tourne avec ce genre de mémoire en ECC du cout je vient de contrôle ma facture et vérifier
sur le site Crucial donc c'est bien de l'ecc ,maintenant si la carte mère ne la supporte pas que vat il se passer pour mon serveur ?
ou alors Crucial ne ma pas envoyer la bonne barrettes ?

Bonjour

Je crois que ta mémoire ecc se comportera comme une non ecc. Par contre je ne sais pas si ta carte les detectera correctement ou pas.

un lien intéressant qui explique les mémoires.
http://www.choixpc.com/memoire.htm

bonjour, ernie
je ni connait pas grand chose en ce domaine alors j'ai envoyer un mail a crucial pour en savoir plus et merci beaucoup pour l'info .

Bonsoir,

ZFS est "auto-réparable à chaud" mais il n'existe aucun moyen de "réparer à froid". C'est pour cela que ZFS procède a des checksum "à tout va", pour être sûr que ce qui doit être fait est fait.

Pour ce qui est de l'ECC ou pas, je raisonnerais de la manière suivante:
Un système pro (serveur) est obligatoirement ECC (il y a certainement une raison ?), le non-ECC étant pour le bas de gamme ou des opérations non à risques.
Pour des ensemble comme les disques durs, on peut utiliser du bas de gamme mais en les montant dans une architecture les rendant fiables (mirroir ou raidz par exemple), mais, pour la mémoire pas d'autre possibilités, c'est une partie unique.
Le problème de mémoire sur ZFS qui pourrait se passer, se situerait surtout sur l'ARC, si ZFS pointe sur un bloc qui ne correspond pas . Par exemple, il crée un nouveau bloc et ensuite décide de l'écrire, il l'écrit, puis met dans son index l'adresse de ce bloc, si l'adresse est faussée (cas du 8 qui se transforme en 7), ce ne sera pas un caractère qui est modifié !, c'est TOUT le bloc qui ne sera plus valable ! soit 128k dans les choux (en général), c'est très conséquent, et ce bloc sera validé car le checksum aura été bon, il n'y aura pas d'erreur pour le système et il n'existera aucune solution pour récupérer ce pb.

Qu'est-ce qui peut altérer la mémoire ?, l'article suivant met bien "les pendules à l'heures":
http://www.commentcamarche.net/faq/3868 ... es-erreurs
On comprend aisément qu'un système ZFS (qui n'a pas de possibilité de réparation à froid, qui ne gère toutes ses données que par un index unique) doit absolument être basé sur une mémoire de type ECC, ainsi que le restant de la chaïne du traitement des données: carte SATA ou SAS et que les disques soient forcément en mirroir ou raidz.

Après ... on peut ou on ne peut pas, tout est une question de moyens.
Si l'on veut faire "du sûr" avec du non-ECC, il faudrait:
- faire un checksum avant de mettre le fichier dans le pool
- mettre le fichier dans le pool
- recopier le fichier ailleurs et refaire le checksum pour vérifier si les deux checksum sont identiques
... pas très pratique, n'est-ce pas ?

Depuis que je suis sur ce forum, je n'ai encore jamais vu de pb de corruptions de ce genre.

Ce n'est pas évident et on pourrait -à juste titre- prendre peur par rapport à tous les systèmes ZFS en fonctionnement qui sont non-ECC ... c'est de la roulette russe, tout simplement.

Page 12 du manuel de la MSI A78M-E35
"Supports non-ECC, un-buffered memory" donc DDR2 classique
Sur un chipset intel de l'ECC ne fonctionne en général pas s'il n'est pas prévu pour (restriction commerciale)
Amd est plus permissif donc une mémoire ECC peut fonctionner mais sans sa fonctionnalité ECC

bonjour,
@sleid
merci beaucoup ,là je le vois noir sur blanc ...."donc DDR2 classique" sa veut dire que je peut mettre aussi de la DDR2 ??

Merci mtiburs
C est clair maintenant.

Je dirais que si on ne peut pas avoir de mémoire ecc, il faut un raid 5 standard et si on a de l ecc le zfs est le bienvenu, tout cela pour une optique de sécurité des données. Certes le raid 5 n aime pas les coupures de courant, mais qu'elle est la probabilité pour que sur une même coupure de courant, 2 disques durs tombent hs ? Je dirais très faibles, et peut être même plus faible que celles des rayons cosmiques.

Je vais patienter un peu pour le zfs quitte à investir dans une carte qui gère l ecc, mais plus tard le temps de me faire la main.

Question: est ce que sur nas4free on peut installer a la fois un zfs et un raid 5. J aimerai mettre un disque de 320 go en zfs pour tester et m habituer aux commandes et notion de dev, pool and co.

Très franchement, je fais une confiance absolue dans ZFS et ce, même sans mémoire ECC, pourquoi ?

1) La façon dont est construite ZFS est bien ficelée, le concept a été fortement bien réfléchit. D'un autre coté on peut se laisser à penser que c'est Oracle qui est derrière, donc, pour des énormes bases de données, pour des volumes monstrueux, le produit doit "forcément" tenir la route.
2) mon expérience perso: des années que mes nas tournent dont 2 qui sont 24/24, pas d'onduleur, sur des petite cartes bas de gamme avec "normalement" pas assez de mémoire, jamais eu de défaut.
3) mes expériences de tests: j'ai aussi fais des test volontaires copier des fichiers multiples et couper le courant ou débrancher un câble de données sur un pool en stripping ... rien, même pas une erreur, on remet en route et ça redémarre comme si de rien était.
4) des configurations complétement loufoques, des pools improbables, des mélanges de genres ésotériques ... jamais eu de soucis (des fois involontaire comme mettre un cache ZFS, mais en me trompant, en l'ajoutant en strip à un pool de 3x2To ! il faut allumer un cierge et faire vite ce qu'il faut
5) Dans mes délires "plus ou moins contrôlés", il m'est arrivé de me retrouver avec un pool qui ne semblait pas cohérent (surtout en iscsi), j'ai toujours retrouvé mes "petits" en exportant et en ré-important le pool.
6) Pour l'anecdote, à une époque, je n'étais pas suffisamment patient lors d’effacement de très gros fichiers et je pensais que ZFS était planté (je ne connaissais pas encore zpool iostat -v 1), en fait, il mettait à jour son travail, et moi (tel un bourrin), je coupais tout ! autant dire que je mettais ZFS dans une position plus que scabreuse, mais là aussi, rien, pas de soucis.

Ma philosophie, et que ce soit ECC ou nonECC, c'est d'avoir une copie des données par sync avec un backup, pourquoi ?
parce qu'un backup de type rsync est performant, simple et se situe sur des contrôle de bloc, donc si il y avait un jour une défaillance dans un bloc, le fichier en question aura été mis de coté, rangé et daté. Ce n'est que mon avis.
Mais je suis et reste profondément "ZFS" pour les données, surtout sensibles.

Pour l'ECC:
On ne peut pas dire "on fait du raid5 si on n'à pas d'ECC et du ZFS si on a de l'ECC", l'ECC c'est valable pour tous les OS et pour tous les FS, un raid5 devra toujours être fait sur une machine ECC, le problème est identique, d'ailleurs avant ZFS, les serveurs ont toujours été en ECC et si possible REGistred (le mode registred étant le plus stable) et toute la chaîne doit être ECC (contrôleur)

Pour finir, ZFS pourra avoir une plus grande portion de données endommagé (128k au lieu de 4ko par exemple) en cas de défaillance mémoire non vue par ZFS, et ce sera pire en cas de déduplication ZFS, car une erreur dans la table de déduplication, et c'est la totalité du pool qui est HS !
Ceci étant, le fonctionnement de ZFS est plus fiable que les autres FS (c'est pourquoi il n'existe pas d'outils de réparation), donc, en gros, même si le risque est égale ou plus important, la probabilité de l'avoir est quasiment nul.

Pour les différentes sortes de FS:
On peut installer autant de pools et de structures différentes que l'on veut, c'est la mémoire et le matériel qui limite les choses.

Mais n'attendez pas d'avoir de l'ECC pour "appréhender" ZFS, ... ce serait vraiment dommage.

ernie wrote:Merci mtiburs
C est clair maintenant.

Je dirais que si on ne peut pas avoir de mémoire ecc, il faut un raid 5 standard et si on a de l ecc le zfs est le bienvenu, tout cela pour une optique de sécurité des données. Certes le raid 5 n aime pas les coupures de courant, mais qu'elle est la probabilité pour que sur une même coupure de courant, 2 disques durs tombent hs ? Je dirais très faibles, et peut être même plus faible que celles des rayons cosmiques.

Je vais patienter un peu pour le zfs quitte à investir dans une carte qui gère l ecc, mais plus tard le temps de me faire la main.

Je crois que l'on ne se comprend pas.

Mémoire ECC ou pas ZFS est de loin le système de fichiers qui permet le plus de récupérations.
N'importe quel système de fichiers se plante avec des erreurs mémoires mais zfs est le plus apte à s'en remettre.
Dans tous les cas une ou plusieurs sauvegardes(paire/impaire) sont toujours nécessaire à la sécurité des données.

Petites réflexions sur les mémoires vives:
Si elles sont utilisées à leur fréquence nominale, et qu'elles sont normalement refroidies, statistiquement soit elles lâchent dans les premières heures d'utilisation soit....jamais.

Depuis quelques années on constate plus de dégradation de la qualité des contacts des supports de barrettes, ils ont tendance à s'oxyder ce qui est également une source d'erreurs. (il existe heureusement d'excellent produits pour pallier à ce phénomène)

La mémoire ECC ne corrige pas les erreurs mémoire mais elle indique au système qu'il y en à une et il s'arrête.

Mais je comprends que le zfs sans mémoire ecc garde lors des sauvegardes les erreurs de mémoires ce qui rend aussi les sauvegardes erronées et non récupérables.
Ai je loupe quelques choses ?

sleid wrote:La mémoire ECC ne corrige pas les erreurs mémoire mais elle indique au système qu'il y en à une et il s'arrête.

... attention à ne pas confondre avec les barrettes à bits de parité, je me souviens en avoir eu sur un 486SX25, c'était des barrettes de 9 ou 36bits (au lieu de 8 ou 32), et à l'époque, j'avais eu un cadeau, j'avais payé une barrette de 4 Mo au prix du HT ... soit 2500fr !!! (j'avais eu l'idée saugrenue de mettre 8Mo ... pour y coller OS2)
Certaines barrettes à cette époque étaient des 9 bits (8bits pour le "normal" + 1 bit de parité. Je me souviens qu'à cette époque les Mac utilisaient des 9 bits (ce qui les rendaient différents des PC ... bon maintenant cette différence ne se situe plus sur le même plan, mais on ne va pas troller ! non non non )

Bit de parité
Les barrettes avec bit de parité permettent de s'assurer que les données contenues dans la mémoire sont bien celles que l'on désire. Pour ce faire, un des bits de chaque octet stocké en mémoire sert à conserver la somme des bits de données.
Le bit de parité vaut 1 lorsque la somme des bits de données est impaire et 0 dans le cas contraire.
De cette façon les barrettes avec bit de parité permettent de vérifier l'intégrité des données mais ne permettent pas de corriger les erreurs. De plus pour 9 Mo de mémoire, seulement 8 serviront à stocker des données, dans la mesure où le dernier mégaoctet conservera les bits de parité.

Barrettes ECC
Les barrettes de mémoire ECC (Error Correction Coding) sont des mémoires possédant plusieurs bits dédiés à la correction d'erreur (on les appelle ainsi bits de contrôle). Ces barrettes, utilisées principalement dans les serveurs, permettent de détecter les erreurs et de les corriger.

Barrettes avec registre ou tampon (registered ou buffered)
Ces barrettes ont un registre entre les puces de DRAM et le contrôleur mémoire du système (dans le chipset ou dans le processeur). Ce registre retient les données pendant un cycle d'horloge avant qu'elles ne soient envoyées vers le contrôleur mémoire. Ce processus augmente la fiabilité du transfert de données, au détriment du temps de traitement, en retard d'un cycle d'horloge par rapport à de la mémoire sans registre. Ces modules de mémoire avec registre ne sont généralement utilisés que dans les serveurs.

source: http://www.commentcamarche.net/contents ... rettes-ecc

ernie wrote:Mais je comprends que le zfs sans mémoire ecc garde lors des sauvegardes les erreurs de mémoires ce qui rend aussi les sauvegardes erronées et non récupérables.
Ai je loupe quelques choses ?

oui c'est exact

- sur une utilisation normale, ce sera un fichier de perdu ou altéré (à voir donc en fonction des données le risque)
- sur une utilisation avec la dé-duplication ET une erreur dans la table, on perdra complètement le pool (le mécanisme de dé-duplication est un système de "haute-voltige" techniquement, on peut avoir des milliers de blocs qui n'auront d'existence que par une seule adresse)

Ce qu'il faut bien ce dire, c'est que ZFS est un système de très-haut-niveau, conçu pour tourner dans des environnement très volumineux et demandant une fiabilité à toute épreuve à condition de lui donner les moyens de fonctionner, la mémoire étant la chose la plus importante pour ZFS.

Mais si on réfléchit bien, on comprendra aussi que l'utilisation des systèmes informatiques grand-public est très risqué, car si on admet que ZFS puisse "un jour" mettre une donnée erronée dans un pool de stockage, on peut aussi admettre que l'acquisition de la donnée ou l'élaboration de celle-ci peut être remise en cause, car rien ne dit que lorsqu'avant que vous ne mettiez la donnée sur ZFS, celle-ci ne soit pas déjà altérée, cela veut dire, que l'utilisation au minimum d'un système de contrôle de parité doit exister ... alors merci au fabricants et aux "têtes pensantes" d'avoir viré les bits de parité des mémoires, car grâce a cette économie, nous ne sommes plus sûr de rien.

alors oui c'est exact ernie, mais il faut appliquer ce raisonnement aussi à tout le reste.


Les cartes-mère ont aussi des différences de fonctionnement, pour une même mémoire, le comportement pourra être différent d'une machine à l'autre, après comment savoir ce qui est mieux ou pas, là on rentre dans certaines religions des marques ou de certains aspects techniques, un tout autre débat !

sleid wrote:Petites réflexions sur les mémoires vives:
Si elles sont utilisées à leur fréquence nominale, et qu'elles sont normalement refroidies, statistiquement soit elles lâchent dans les premières heures d'utilisation soit....jamais.

Pour information, j'avais deux barrettes de mémoires Kingston Hyper-X en 2133, ce sont des barrettes avec un gros radiateur, la machine ou se situent les barrettes ne chauffent absolument pas (il fonctionne toujours au ralentit) car le système de ventilation du boitier et proc est sur-dimensionné au départ.
La fréquence est aussi utilisée correctement, ce sont des 8Go (donc 16Go d'installé)

J'ai eu un jour une impossibilité de faire des import et export de machines virtuelles sous Virtualbox (j'ai donc sauvegardé mes mv par copie des fichiers directement), j'ai mis ça sur le compte de vbox, car la version venait de changer suite à une mise à jour.
Mais pendant au moins deux mois, 5 mv sous Windows XP ont tournées dessus en même temps et sont utilisées régulièrement.
La carte-mère fonctionne 24/24.

C'est un jour, que certains utilisateurs ont relevés des trucs bizarres.
Ne comprenant plus, j'ai utilisé un live/CD de knoppix et j'ai testé la mémoire avec testmem (choix au boot du cd), une des barrettes étaient HS.
J'ai changé de place les barrettes et les ai testé séparément, le test passait en défaut immédiatement sur la barrette défectueuse.
J'ai mis la barrette sur mon i5-2500/asrock-b75 et le premier test passait mais passait en défaut après (donc au deuxième test).

J'ai utilisé le service Kingston car les barrettes sont garanties à vie et j'ai reçu un lot neuf très rapidement.

Donc, une bonne barrette de marque, non chaude et utilisé à la bonne fréquence peut déconner et "continuer à vivre" comme si de rien était. C'est peut-être un cas rare, mais c'est une expérience vécue.

Merci pour ce compléments très instructif.

Donc, une bonne barrette de marque, non chaude et utilisé à la bonne fréquence peut déconner et "continuer à vivre" comme si de rien était. C'est peut-être un cas rare, mais c'est une expérience vécue.

J'avoue avoir déjà eu ce genre de soucis également, pas facile la première fois de déceler le problème ...

Et bien, j'avoue qu'une machine qui fait tourner 5 Windows XP sous Virtualbox en Linux/Debian, 3 VM sur 5 jours sur environs 10 heures (dont 2 VM qui tournent H24) avec un test mémoire qui plante instantanément, ça me surprendra toujours et je me demande toujours d'ailleurs comment c'est possible.
Le seul truc que je n'arrivais pas à faire, c'est de réimporter une VM qui a été exporté par cette même machine, sur le coup j'ai mis la faute à une mise à jour de vbox car c'est arrivé juste après (me suis dis que l'import avait un soucis, vu que l'export fonctionnait bien).
Cela à duré un à deux mois.
En fait, j'aurais préféré que ça plante carrément les choses, car du coup, je ne sais pas si certaines données n'ont pas été "picorés". A priori non. Je pense avoir "un peu" de bol

C'est dans ces moments là qu'en y réfléchissant bien, on comprend mieux l'ECC

grand public = on démarre "tout debout" et on fait sans savoir
professionnel = on teste, on valide et ensuite on démarre l'OS en contrôlant si tout ce qui passe est bien correct

C'est vraiment deux mondes différents.