Reprise du message précédent :
Sur freeBSD aucune idée, je suis sur Unraid et j'ai suivi des tuto en ce sens avec powertop pour tester (qui existe peut etre aussi chez toi).
 
Après faut penser aussi a activer toutes les options d'économie d'énergie dans le bios

120K plutôt oui, il est en fonctionnement quasi non stop depuis 2006 (date d'achat).

Alors, feedbacks sur mon HDD Seagate Exos X18 16tb (ST16000NM000J)

- Achat Amazon reconditionné (vendu par Amazon, j'avais hésité avec ceux vendus par Digital Emporium GmbH)
- Payé 228 euros (20 balles de plus que Digital Emporium)
- Warranty Valid Until 21 décembre 2027
- Test badblocks terminé, 40 heures et aucune erreur
- 44 heures de fonctionnement à l'installation (88 maintenant)

Et voilà le résultat SMART :

Pour les néophytes comme moi, coup de pouce ChatGPT

Bref, je valide et je garde le disque en prod

 
Je m'étais bien mis en Energy Efficient sur le profil CPU.
Après j'avais viré les ACPI comme Suspend ou autres car il est allumé tout le temps. J'ai peut-être tort sur ce point là.
 
Je peux visiblement installer PowerTop sur FreeBSD. Tu pourrais m'indiquer le lien vers le tuto que tu as utilisé ? (histoire de voir ce que je peux faire)  
Merci !

 
J'ai 2 Toshiba 2 to qui m'ont claqué dans les pattes au bout de 3 ans H24.

https://forums.unraid.net/topic/980 [...] -powertop/

 
Merci beaucoup !

Avec TrueNas, je pensais commencer avec 1x 16to et passer en 2x 16to zfs mirror rapidement.
 
Faisable ? Ou il vaut mieux attendre d'avoir le deuxième hdd et commencer directement en zfs mirrror (ou raidz1?)
 
Si je comprends bien le zfs mirror ne marche que par paires, alors que raidz1 je devrais pouvoir ajouter 3eme hdd dans le futur pour passer à 32go de capacity ?
 
D'autres considérations à prendre en compte pour faire le choix ?

Sur le papier c'est ça, oui le RAID1 permet de ne pas avoir d'interruption de service (mais on doit toujours avec des backups, ça n'empêche pas la corruption de données, ou l'accident bête ...)
 
Par contre, la proba d'une panne d'un SSD, surtout en tant que boot drive, elle est proche de ZERO quand même... Donc du RAID1, c'est p'tet un peu useless...
Perso pour l'instant sur ~15 SSD, je suis toujours a 0 défaillance, et certains ont plus de 10 ans maintenant... Bon du coup c'est du MLC de TRES haute qualité vs ce qu'on a aujourd'hui... mais bon...

/!\ L'ECC n'empêche pas la corruption de donnée. C'est un faux mythe. /!\
 
Au-delà de ça, même si en ZFS la RAM joue beaucoup, le pb c'est que pas mal de la chaine de la RAM a la cellule NAND du SSD (ou le plateau du disque), n'est pas vraiment résilient. Du coup...
 
En réalité, pour qu'il y ait un risque beaucoup plus grand sans ECC qu'avec ECC, il faudrait qu'une donnée depuis longtemps en RAM soit réécrite. Sauf que ce use case ne doit pas se produire, puisque si on écrit, c'est que la donnée a changée. Donc la zone mémoire utilisé comme cache de lecture ne sera pas utilisée comme source pour l'écriture.
 
 
 
 

Improbable car :
- en déplacement c'est une action au niveau du SGF, les blocks de données ne sont pas touchés, donc sauf à avoir un SGF moisi qui n'a pas de redondance, genre FAT, y'a ~0 risque
- en copie, la source étant fraichement en RAM, même sans ECC, vu la probabilité d'un flip de bit et la durée du processus, le risque de corruption est proche de zéro.
 
Après oui si y'a un p'tit coup de rayon cosmique qui touche la barette RAM pile à sa moment...

 
Non, cas du scrub de ZFS qui pourrait tout te corrompre alors qu'aucune donnée n'a changé si la RAM est foireuse.

 
 
Pour du raidz1 il te faut obligatoirement 3 disques minimum. Et je suis pas sûr que tu puisse passer d'un 1x16to à un mirror facilement. Le plus simple est de commencer directement avec 2 disques pour du mirror ou 3 pour du z1.

 
mais si
 
https://openzfs.github.io/openzfs-d [...] ach.8.html

Ça m'a l'air bien compliqué tous vos trucs là

Avec mergerfs et snapraid, même avec mes 2 pauvres gigots de ram j'ai pas de soucis à ajouter/retirer un disque et les performances sont larges pour regarder un divx sur ma télé 32"  

Mais en vrai j'aime bien ce couple facile à mettre en marche et (je pense) évolutif.
U' petit scrub/sync 3 fois par semaine et une copie complète sur 2 disques externes en rotation que je vais planquer dans la salle serveur du taff, ça doit le faire.

 
Je ne suis pas un expert du ZFS, mais de ce que l'on trouve dans la doc, vu la description, cette opération de scrub n'utilise pas de cache, mais réalise des I/O sur les disques physiques. Donc sauf à avoir vraiment un sous-système RAM instable pour cause de panne dans une puce RAM ou de problème de chipset/fréquence/timings RAM (qui le serait tout autant avec ou sans ECC du coup), y'a vraiment peu de risque qu'il y a une corruption...
 
Après sinon j'aurai tendance à dire que si on a si peur de tout ces risques c'est que p'tet on prend le problème à l'envers et que la solution serait d'abandonner ZFS...

J'suis d'accord a avec MEI.

-> Le seul 'risque' d'une corruption de données sur un système ZFS qui serait du à la mémoire non ECC, c'est lorsqu'on 'disable' désactive le réglage 'sync' d'un volume ou dataset dans le cas d'une écriture.

Le flux de données écrit vers le stockage est donc inscrit en RAM avant d'être écrit de façon réguliere sur les disques (toutes les 5 sec par défaut) et si jamais en effet la RAM est non ECC et ne renvoie pas la 'vraie' donnée, ce qui sera écrit sur le disque sera la donnée incohérente.

Pour l'avoir expérimenté, cela généralement plante la copie / génére lorsque le protocole au dessus de la couche bloc (lorsque c'est du stockage type volume) fait son checksum.

Le scrub ne fait qu'une vérification de la cohérence du POOL composés de/des grappes VDEV, a la limite le 'resilver' d'un VDEV (qui ré-écrit sur le nouveau disque) pourrait éventuellement causer une incohérence de données dans le cas où est stocké un volume ou dataset avec ce fameux settings de sync=disable ? Et encore, je suis pas certain.    

Ce système de stockage est vraiment mature en tout cas, j'ai quelques peta octets en production   repliqués sur plusieurs baies :-]

 
Ce qu'on te dit c'est une RAM foireuse non ECC va avoir le scénario suivant :  
-lecture sur le disque pour calculer le checksum
-en vrai, les données sont bonnes sur le disk
-à cause de la RAM foireuse, le checksum calculé (ou la data lue) peut être faux en RAM
-donc ZFS va vouloir corriger la data, donc réecriture d'un truc débile sur le disque qui était bon à l'origine.
 
Ce scénario ne peux pas arriver avec de la RAM ECC.
 
edit: attention, la probabilité d'un tel scénario est assez faible hein. Faut vraiment que la RAM soit juste un tout petit peu foireuse pour ne pas crasher le système mais quand même un peu pour corrompre les datas.

 
Lors d'un scrub, c'est le CPU qui calcule le checksum avec des données issues directement du disque, le cache utilisé pour cette opération est donc le cache interne au processeur, pas vraiment la RAM...

A quel moment la RAM est-elle sollicitée pour faire "foirer" l'écriture ou la lecture ?

Il faut prendre le postulat que le PC est stable : i.e. CPU/contrôleur RAM/RAM sont dans des specs correcte. C'est assez facile à vérifier, et un PC moderne avec de la RAM dans les specs du JEDEC, @ stock c'est du memtest pendant 1 semaine sans erreurs assez easy en fait...
 
Du coup la proba qu'un bit swap est TRES faible sur un délai relativement court de quelques ns/ms/s le temps de réécrire.
Et surtout si le sous-système RAM n'est pas stable stable, l'ECC ne va pas aider tant que ça, car ça a une capacité limitée à corriger les choses...

 
Quand les données transitent du disque vers l'extérieur (ou l'inverse) ça passe par la ram à un moment.

 
Lorsque la donnée passe par elle, lorsqu'il y a écriture sur le disque, il y a aussi écriture dans la mémoire ARC (dans la RAM donc) le but étant d’accéder plus vite a la donnée.
(au moins pour une durée assez courte, et si l'ARC est proche du max utilisée, la donnée sera effacée de la RAM et relue depuis le disque lorsqu'il y aura besoin de la relire plus tard)
 
Le problème potentiel, c'est qu'en effet, la re-lecture de la donnée depuis la RAM peut dans certain cas être mauvaise, mais la donnée sur le disque est toujours bonne elle.
 
Lors d'un SCRUB (vérification périodique de la cohérence des données issues des disques) il y a re-lecture depuis les disques et calcul d'un cheksum, la RAM dans ce cas de figure n'est a mon sens pas réellement utilisée.
Idem lors d'un RESILVERING (reconstruction d'un disque avec les données issues des autres disques)
 
L'information n'est pas suffisamment claire sur ce point je trouve.
 
Pour les anglophones, y a une doc qui parle des situations où c'est possible ainsi que du processus exact de calcul de checksum :
https://research.cs.wisc.edu/wind/P [...] fast10.pdf

C'est intéressant... Mais pourquoi sur le forum de TrueNAS, ils nous interpellent si on n'a pas de la RAM ECC du type : "faites ce que vous voulez mais si vous voulez vivre dangereusement..."

 
J'avais lu le contraire, je vais regarder

Même si c'est infime, il peut y avoir une corruption de données donc prudence, c'est pour cela qu'il est recommandé de mettre de la RAM ECC.
 
En production / et stockage froid de sauvegardes, y a pas de le droit a l'erreur donc la question ne se pose pas.
 
En usage personnel, le risque existe toujours, mais d'une, il y a probablement moins d'activités / écritures & lectures statistiquement cela n'arrivera peut-être jamais (et sur très très peu de quantité de données au final) et en plus la criticité est relative.
Excepté si tu as le cas de figure de ouf qui fait que ta RAM devient d'un coup défectueuse PENDANT un scrub alors là ... pas de bol ...

Tous n'ont pas ce discours.  

Raidz1 c'est du raid 5.  

 
Je confirme ! Toutes mes grappes de HDD sont en RAIDZ1 et utilisent 3 disques.
 
J'avais d'ailleurs hésité à les regrouper en une seule grappe RAIDZ1 :
de 2x 3 HDD 10 To (~40 To utile) à 1x 6 HDD 10 To (~50 To utile)
 
Est-ce jouable ou complètement débile/risqué ?
 
Thanks  

Faut se le dire, les mecs qui font NAS perso sous TrueNAS reste des barbus hein. Et dans le lot, je ne suis pas sûr que beaucoup comprennent a la fois le fonctionnement SW de TrueNAS, mais aussi et surtout du HW.
 
Parce que comme beaucoup disent, si tu fais un round-trip entre le NAS et un PC client, qui lui n'est pas ECC, tu ne restes plus sûr de rien.
Autrement dit, admettons tu as un document Word sur ton NAS, bah si après modification, ça se corrompt pendant cette modification ou sur le chemin du retour vers le NAS, le NAS tout ECC qu'il aura écrira quand même de la merde...

 
J'avais vu ici : https://raidz-calculator.com/raidz-types-reference.aspx
 
Min number of disks: 2
 
Mais après avoir pas mal creusé le truc je vais partir sur du mirror je pense
 

Si tu as deux disques et qu'il y a un disque de parité, cela revient à un bête miroir...

Et TrueNAS, il précise MIRROR ou RAIDZ1 en fonction du nombre de disques...

 
Oui mais tu peux en rajouter un 3eme en raidz1 (soon).
Pas en mirror?

 
Oui, là, c'est sûr... Après, je n'ai jamais essayé d'agrandir une grappe...

Mon premier SSD vient de caner. Et sans prévenir. Un Sandisk Plus de 2021. J'ai meme pas atteint le TBW par contre j'ai apparemment atteint le nombre d'effaçages/ecritures et consommé 100% de l'espace de spare. Je m'en suis rendu compte parce que le débit est maintenant freiné à 3Mo/s et que ça m'a pris une éternité de répliquer un disque de container d'un node Proxmox à un autre. Je pensais à une défaillance de l'adaptateur réseau mais en fait c'est juste le SSD qui est cramé.

Pourtant il n'est qu'à 60 ou 80 TBW sur 600 mais bon...

J'ai reçu mon deuxième hdd 16to (j'ai pris un ironwolf pro cette fois).
RAS, 0h d'utlisation à réception et badblocks check ok.
 
J'hésite encore entre TrueNAS et Unraid en VM proxmox.
 
Unraid a l'air vraiment sympa / user friendly mais la license à 250 balles ça fait chier
 
Je pourrais prendre la licence annuelle, mais une fois qu'on a setup le système je me vois mal changer d'ici 1 an. Donc autant prendre la license à vie direct

Tous les licenses sont a vie, juste que tu as les Maj uniquement le temps indiqué

 
En VM j'ai du mal à voir l'intérêt. Autant claquer un Linux + container Samba.

Hello,
 
utilisateur Unraid en v7 beta3.
Pour la première fois j'utilise les snapshots sur une des mes VM .
J'ai l'impression que depuis que j'ai fait un snapshot la VM est moins reactive.
normal ?
 
Pour revenir en arrière, j'ai fait un "blockpull" du snapshot. le blockpull est extrèmement lent. (J'en suis à 25% en 24h). Est ce normal ? (C'est une image disque de 1To).

 
Ouais utiliser n'importe quel truc (et encore pire, un truc critique comme un NAS) sans MAJ c'est pas vraiment idéal
Sauf si ils garantissent des security patch à tous ?
 

 
Une belle interface, gestion du RAID / sauvegardes / etc?
Je vois des tonnes de personnes ici et sur reddit qui ont Unraid ou TrueNas en VM sur proxmox, c'est tous des ânes ?

Non mais pourquoi ne pas le faire tourner sur le host physique directement? Ça peut aussi faire office d'hyperviseur