Carte Mère Eco avec Nombreux Ports SATA

[CorbeilleNews]

Bonjour,

Connaissez-vous des cartes mères fonctionnant avec des processeurs faible consommation (si possible fanless) et ayant au moins 10 ports sata ?

Quand on regarde sur les sites internet (materiel.net ou LDLC par exemple) il y a des dizaines de cartes et aucun filtre pour simplifier le choix sauf à les éplucher toutes ...

D'avance merci

[sleid]

C2550D4i 12 ports sata (8 sata 3 + 4 sata 2)
C2750D4i 12 ports sata (8 sata 3 + 4 sata 2)
Fanless si la ventilation du boitier est très efficace + radiateur sur les 2 contrôleurs Marvell

[CorbeilleNews]

Bonjour Sleid et merci

Je les avais vu sur LDLC mais comme elles n'étaient plus commercialisées j'ai donc pensé qu'elles n'étaient plus produites.

Cependant j'ai une machine qui devrait contenir 18 disques, et avec 12 SATA et juste un PCI-E pour une carte contrôleur additionnelle de 4 SATA cela ne permettra que de brancher 16 disques.

Avez-vous connaissance de cartes pouvant contenir plus de connecteur SATA ou un port PCI-E supplémentaire pour brancher une seconde carte contrôleur ?

Quid des failles Meltdown et Spectre sur ces CPU ?

Peux-t-on remplacer le CPU en cas de panne ou d'évolution sur ces cartes ou est-il soudé ?

Y a t-il d'autres marques qui font de telles cartes ? Avec ou sans CPU intégré, quel type de CPU faut-il choisir ?

Comment connaitre leur consommation ? J'aimerais pouvoir quantifier le gain d'énergie avec le matériel actuel.

Ces cartes seront-elles suffisantes pour du Raid-Z2 de 18x4To ? Actuellement cela fonctionne très bien avec un i5 et 32go de ram (je sais qu'il faut 1go par To en ZFS mais cela tourne sans problème depuis des années : c'est juste de l'archivage de vidéos et je ne dépasse jamais les 40% utilisés même lors des transferts) mais le CPU sera t-il suffisant lors de recherches de fichiers par exemple ou les synchro rsync ?

D'avance Merci

[mtiburs]

Bonjour,

Perso pour votre cas, je ferais la chose suivante:

- 1 carte-mère avec 2 ou 3 ports PCI-express
- chaque port PCIexpress contient une carte SAS (récente ou d'occase: pour info une fois j'ai acheté un lot de 10 carte Perc6/ir (256Mo/cache interne) pour 100e (10e par carte), c'est ce que j'utilise sur mon bi-xéon (car elles ne sont pas trop longues et ont l'avantage de "passer", alors que j'ai une super carte LSI à 1Go/cache qui est trop longue !
- Je mettrais les disques à l'extérieur, surtout pas dans un seul boitier (version bidouillage= des rails (4 rails équerres) à trous dans les magasins de bricolage et les disques tiennent tout seuls grâce à leurs vis. Sinon, il existe des boîtiers "fait pour", ou alors des boîtiers ATX de récup (lol, je vais en jeter une dizaine :-/ ), pour l'alim des disques: des alim de récup ou pas cher (mais bonne/suffisante) qui poussent l'air sur les disques (pour bénéficier de la ventilation gratuite)
Pour info, j'ai 4 barres d'1m et on peut mettre 16 disques d'un coup (barre à l'horizontale et disques à la verticale)
- je prendrais des câbles SAS (c'est compatible SATA, mais pas l'inverse) de 1m (aliexpress: 12e à 18e: je remplace les molex de m...e par des sucres, comme çà pas de faux contacts.)
- j'utiliserais un ou deux SSD pour le Zcache (en secondarycache=metadata), et ce uniquement si il y a une forte charge, perso, j'utilise des disques SAS en 15k7 (temps d'accès très bon dû aux 15000tr/mn, même si c'est des disques anciens 36 ou 73Go, le top des Seagate 15k7 (les disques les plus véloces qui existent)
- éventuellement, j'utiliserais deux disques miroir pour le log (mais, c'est uniquement si la charge est très importante en écriture), car la plupart du temps, ZFS "boude" mes Zlog (moi j'utilisent des disques SAS de 36Go/15000tr/mn à 5e pièce !)
Mais par expérience ("petite" car non-pro), un raidZx suffit pour tout faire

Voilà ce que je fais en gros (j'ai un énorme boitier tour, mais je ne veux plus que 2 ou 4 disques durs dedans ... et 16 (ou 24) dehors

Sinon, j'ai mis au point une technique (qui était en essai) qui rend le pool totalement indestructible (je passe par un nas4free intermédiaire), à terme chaque dev par un nas4free (en fait chaque dev:disque dur physique est snapshot-able: donc un pool), je pensais faire peut-être un post sur le sujet mais c'est pour les méga-parano et je ne sais pas si il y en a des aussi fêlé que moi
pour l'instant: j'ai 4 disques SAS de 2 To de cette façon, c'est 2 fois moins rapide qu'en "direct"! (car c'est à base d'iscsi), mais çà résiste à TOUT (c'est vraiment pour les ultra-ultra-paranos: détruire le pool, et formatage en ntfs des disques, on coupe le courant ... 1 seconde après , le pool revient "nickel") ... cool quand il y 4 miilions de fichiers

[sleid]

10 ports sata ou 18 disques ce n'est pas du tout la même chose......
Pour 18 disques, comme le dit mtiburs, il faut passer par du sas et dans ce cas de multiple ports pci.
Cependant les cartes mère ayant de nombreux port pci ne rentrent plus dans la gamme basse consommation avec des processeurs type Atom (18 à 30 w) mais plutôt des cartes à base de xéons qui même en version basse consommation dépassent les 50 w soit l'équivalent de votre I3.

Si vous souhaitez rester dans la gamme Atom et en attendant un peu vous devriez trouver votre bonheur avec la MA10-ST0 de Gigabyte, c'est toujours du sata bien que les connecteurs soit en mini-sas mais il y en a 16 natifs et elle dispose d'un port pci.
http://b2b.gigabyte.com/Server-Motherbo ... -rev-11#ov
C'est une véritable carte mère serveur avec ipmi et 2 lan 10gbit/s.

Je ne connais pas la capacité unitaire de vos disques, mais c'est sur ce point que les économies d'énergie se font, quelle que soit la capacité du disque la consommation reste la même.
Un disque de 6 To consomme 6 fois moins que 6 disques de 1 To.

[mtiburs]

une question:

Quelle va être le type et la proportion des données ?

Est-ce qu'il va y avoir des données "complètement figées" ? (je veux dire par là des données en lecture seule qui sont là juste pour être à dispo)
Car très franchement, faire un pool de 18 disques en SATA qui serait sans "chaîne" ECC (çà va de la RAM aux disques: le SAS est ECC) c'est un très gros risque.
De plus, quand on fait une machine de ce genre, il faut prévoir une réponse à un problème (si la carte mère flanche, que fait-on ? combien de temps pour faire repartir le pool ?

Selon la proportion de données figées (on va dire en lectures seules: données qui n'ont plus a être modifiées), perso, je mettrais un disque avec un pool en lecteur seule (avec un autre en double en sécurité ou sur un raspberry mais délocalisé)
Je monterais ce type de données en NFS et je ferais des liens pour qu'il se trouve aux endroits voulus.
J'ai un serveur de 2x2To en miroir qui ne contient 17Go de données "vivantes", le reste ce n'est que des archives, et bien je suis en train de me poser la question pour savoir si je ne peux pas rendre tout çà moins vorace. Quelquefois çà vaut le coup de passer un peu de temps a déplacer des données dans des autres endroits.
Pour moi, avoir un énorme pool:
- c'est un luxe (expliqué ci-dessous)
- çà demande une configuration adéquate (chaîne ECC partout, ne pas pas oublier qu'une erreur d'adresse en ZFS peut amener à une perte totale, plus le pool est important, plus il faut de la sécurité: ZFS a été conçu pour de la mémoire ECC, il peut marcher sur un rasperry pi2b c'est cool, mais arrivé à une certaine taille et avec une certaine importance dans les données, il faut être "sérieux")
- çà demande un "doublement" du matériel (beaucoup d'entreprise ont une carte mère en double, surtout quand c'est spécifique, çà fait des fois le bonheur de certains, j'ai obtenu ma carte mère bi-xéon de cette façon, elle traînait (neuve non déballée)dans sa boite en haut d'une armoire et je l'ai eu pour 99e !)
- çà demande un doublement aussi coté sauvegarde (imaginons un pool qui ne veut plus se monter ?), pour moi avoir un seul pool sans sauvegarde est une "pure folie".

Une autre question:
- y aura t'il des datasets ? là c'est pareil, il faut faire le tri, car en fonction des données on peut très bien imaginer une structure modulaire ou l'on a un serveur avec deux ou trois gros disques en miroir ou raidz et le reste provenant d'une autre machine (qui pourrait prendre le relais en cas de panne) par exemple:
1 serveur A (contient un pool important) + montage NFS
1 secours B du serveur A (qui contient les export NFS)
des machines réduites qui contiennent les sauvegardes
comme çà:
en cas de soucis B peut recevoir le pool de A et les montages NFS peuvent provenir des machines de sauvegardes

Je ne fais que lancer des idées, si le but est d'avoir un seul pool .. je peux le comprendre mais il faut bien "tout prendre" en considération.

[mtiburs]

Bonjour,

Petit ajout;
Il existe un autre FS que ZFS pour faire un énorme pool, c'est BTRFS (ZFS et BTRFS sont très liés par leurs auteurs, la seule différence réside dans le fait que ZFS est en gestion "blocs" alors que BTRFS en gestion "fichiers".

Si votre idée est de faire un énorme pool de 18 x 4 To, soit 72To - 1/2/3 disques qui sera "très figé" dès le départ, qui sera peut-être un jour dépassé, il peut être intéressant de faire ce pool en BTRFS.
Pourquoi ? parce qu'avec BTRFS, vous pouvez agrandir et modifier votre pool (à chaud si en SAS), avec du raid1 pour les métadatas et du raid1 aussi pour les données, vous pouvez également recompresser/défragmenter les données quand cela vous plaît.

Petite remarque au passage: imaginez 18 disques qui tombent en panne tous en même temps ! (même fabrication, même composants), car si les disques sont réellement identiques, à cause du raidz, ils vont s'user strictement de la même façon, donc, de forte chance de tomber en panne en même temps.

Le raid1 en BTRFS se fait en tant que fichier (non pas par "bits physiques", c'est à dire qu'il veut juste mettre 2 fois le même fichier sur deux supports différents, peut importe l'endroit !)
L'avantage c'est que vous pouvez mettre vos disques "n'importe comment", peut importe la taille des disques (pas besoin de 18 disques durs de tailles identiques), vous pouvez mélanger les types comme bon vous semble (BTRFS gère tout cela et fait en sorte que les données soient toujours en respect du raid1 "fichier").
Par exemple, si 4 disques de 4 to vous gênent par leur nombre, vous pourrez un jour en mettre un de 16To à la place, et vous récupérez les 4To, de cette façon vous pouvez avoir ainsi l'objectif de réduire le nombre de disques au maximum.

L'inconvénient, c'est que votre pool coûtera le "double" des disques, mais l'avantage, c'est la souplesse (et au lieu de partir directement sur 18 disques, vous pouvez démarrer avec x disques de 10To, puis vous rajoutez des 8,6,4 To au besoin (puis vous rajoutez un 10, et vous enlevez les petits disques)

Ce n'est pas du ZFS et ce n'est pas sous Nas4Free , je sais, mais bon, faire un choix n'est pas toujours évident.



sinon, pour en revenir à ZFS (et à la suite de mon dernier post):
- une machine fanless avec 2 ou 3 disques en miroir (les temps d'accès diminueront et les débit s'accumuleront) sur la lecture (comme un raid0) pour des fichiers primordiaux (idéalement disques en SAS)
- d'autre machines fanless avec des disques SATA montés en NFS (mais qui pointent sur la racine du pool de la machine principale)
c'est à dire:
machine 0 (principale) = gros pool véloce
machine A moyenne (contient la taille d'un ou des dataset(s) qui aurait été sur la machine normale
machine B légère (contient la taille d'un ou des dataset(s) qui aurait été sur la machine normale
/pool/dataset1 (machine 0)
/pool/dataset2,3,4 (en fait des liens vers un montage NFS, qui provient de /pool1 de la machine A)
/pool/dataset5,6,7,8 (en fait des liens vers un montage NFS, qui provient de /pool1 de la machine B)
l'avantage, c'est que vous pouvez utiliser des petites machines, couper des bouts de la structure, et la modifier facilement.
les datasets seraient déplacé par zfs send ou recv lorsque le besoin s'en fait sentir, en tâche de fond, un rsync pour la mise à jour finale, un nouveau lien et c'est partit !
Les montages NFS pourraient avoir l'option FSC (cache en lecture) sur la machine principale

Avantage1: matos plus petit, modulaire à souhait, et structure plus résistante à la panne (parce que sectorisé)
Avantage2: moins de consommation (moins de disques) et parties pouvant être stoppées)
Inconvénient1: un peu plus de réseau
inconvénient2: il faut suivre l'évolution de sa structure (pour déplacer l'équivalent d'un dataset pour s'adapter)

[CorbeilleNews]

Pour répondre en vrac à vos réponses, le pool est un raid-z2 de 18x4To soit 16x4To utiles.

C'est un usage loisir car il ne contient que des enregistrements FreeBox. Avec un, voir deux clients osmc sur raspbery qui tournent uniquement le matin et le soir pour les visionner (débit 2-3 Mo/s cumulés)

Donc vous voyez c'est un usage domestique plutôt soft. Il est bien rempli et je ne modifie que quelques giga par jour : ajout / retrait de quelques enregistrements uniquement.

Je n'utilise pas d'ECC car je ne voyais pas vraiment l'utilité pour l'usage ??? Qu'en pensez-vous (les données restent ecrites sur les disques non ?)

Concernant un backup d'un tel volume : il a un coût assez important.

Le NAS tourne presque 24h/24 depuis 3-4 ans et les disques passent en veille au bout de 20 minutes pour économiser de l'énergie (de 160w en écriture à 80w en veille la journée)

A l'origine il était composé de 6 disques de 2 To (RAID-Z2 toujours) mais le manque de place (volume de données) m'a obligé à augmenter dans un premier temps la taille des disques puis leur nombre dans le Pool car les disques plus gros sont toujours hors de prix ...

La multiplication des disques utiles par rapport à ceux de "redondance/parité" m'a permit aussi a l'époque de diminuer le cout du Pool et c'est pour cela que j'avais rapidement choisi un gros Pool 10 disques RAID-Z2 puis 18 :

1. Je souhaitais éviter d'avoir plusieurs Pools pour ne pas multiplier l'ensemble des disques de redondances (taille du boitier et nombre de SATA disponibles)

2. Je souhaitais aussi éviter de multiplier le nombre des partages : quand je cherche un fichier je n'ai a le chercher que dans un seul partage et pas dans les x partages des x Pools créés

3. Connaissant les besoins grandissants et le fait que le nombre de disques d'un Pool serait figé au départ j'ai préféré partir d'emblée sur un gros Pool (cela répondait aux deux premiers points). Même si je savais qu'il faudrait changer tous les disques pour étendre la taille globale du Pool car j'avais déjà été limité sur une précédente config avec moins de disques : trop cher de monter des disques de plus grandes tailles (inondations à Taïwan il me semble)

A l'époque et d'après mes recherches et connaissances je n'avais pas trouvé de solutions plus économiques car cela permettait et me permet encore de prendre des disques avec un meilleur prix par Go.

Vu l'utilisation j'utilise du Sata 5500-6000 tours ce qui est bien suffisant pour saturer la bande passante Ethernet (même en cas de transferts de fichiers) cela consomme moins et fait moins de bruit que du 7200 ou du 10K.

Pour des disques plus gros je suis d'accord mais cela a encore une fois un surcoût au Go (ce sont en général des disques assez chers car pas encore courants), d'autant que dans cette config il est difficile de diminuer le nombre de disques du Pool, je vais regarder du côté de btrfs mais j'avoue que le fait de savoir se débrouiller déjà un minimum avec nas4free reste un confort et les besoins grandissent plus vite que les capacités/coûts des disques, c'est pourquoi je maintien le nombre de disques dans le Pool.

J'ai conscience que tout n'est pas parfait mais l'usage n'est pas industriel non plus. A l'époque la robustesse affichée de ZFS par certains d'entre vous m'avais convaincu de prendre ces risques "mesurés" et bien sûr dans les premiers mois les données étaient backupées ailleurs.

Économiquement cela s'avérerait désormais difficile. D'autant que j'ai d'autres NAS plus petits dans le même esprit pour lesquelles il faudrait faire pareil ...

Pour la carte mère en cas de panne je peux patienter le temps d'en racheter une ou en trouver une d'occasion/neuve en prévision d'une panne.

Merci

[sleid]

Lorsque votre pool ne sera plus accessible et en plus impossible à importer vous vous souviendrez de l'utilité de la mémoire ECC.

[mtiburs]

(mes réponses en bleu)

Pour répondre en vrac à vos réponses, le pool est un raid-z2 de 18x4To soit 16x4To utiles.

C'est un usage loisir car il ne contient que des enregistrements FreeBox. Avec un, voir deux clients osmc sur raspbery qui tournent uniquement le matin et le soir pour les visionner (débit 2-3 Mo/s cumulés)
Donc vous voyez c'est un usage domestique plutôt soft. Il est bien rempli et je ne modifie que quelques giga par jour : ajout / retrait de quelques enregistrements uniquement.
En fait soft ou pro, le montage d'un raidz de cette taille est le même, et cela ne change rien.

Je n'utilise pas d'ECC car je ne voyais pas vraiment l'utilité pour l'usage ??? Qu'en pensez-vous (les données restent ecrites sur les disques non ?)
L'ECC garantit une non altération des I/O
ZFS fait des checksums et les données écrites et lues sont constament surveillées, donc oui les choses sont bien gérées.
L'ECC est surtout important dans la fiabilité et pour la non altération des données, l'ECC non registry fait que le système s'arrête instantanément et ne provoque pas de corruption, l'ECC registry, fera en sorte de faire un pas en arrière (donc revient sur la dernière instructions et reprend son petit bonhomme de chemin).
Un serveur conçu en ECC est un serveur (le but étant de "servir", il fera son boulot quelque soit les altérations possibles: champs magnétiques ou rayons cosmiques:
Une interférence électrique ou magnétique à l'intérieur d'un ordinateur peut changer la valeur d'un bit de mémoire vive DRAM. On a d'abord pensé que ce phénomène était principalement dû à des particules alpha émises par des contaminants dans les matériaux utilisés dans la fabrication des modules DRAM, mais la recherche2 a montré que la majorité des erreurs dans les mémoires DRAM se produisent à la suite de rayonnement de fond, principalement des neutrons émis par des réactions engendrées par des rayons cosmiques. Ces neutrons peuvent changer le contenu d'une ou de plusieurs cellules de mémoire ou interférer avec le circuit utilisé pour les lire ou les écrire.

Le problème avec ZFS, ce n'est pas les données, c'est pour une valeur d'indexation, par exemple vous voulez lire la page 30 d'un livre et au lieu d'en déduire que c'est la 30, vous vous dites que c'est la 39, ensuite vous pouvez faire tous les contrôles possibles, écrire scrupuleusement partout que c'est la 39, vous irez voir cette page 39, mais ce n'est pas celle là qu'il faut aller voir !
C'est là le hic

Personnellement, j'ai vécu ce genre de situation, j'ai monté de la mémoire non ECC sur mon bi-xéon (16Go) et je l'utilisais régulièrement (machines virtuelles sous Vbox et ZFS), la personne qui m'a vendu la mémoire (de la KVM de marque) m'a dit, vous faites ce que vous voulez, mais je vous conseille fortement de mettre de l'ECC.
C'est à force de me retrouver avec des erreurs sur mes pool que je me suis posé la question (je faisais des scrubs, des clears et je supprimais les datasets qui contenaient les erreurs, quelquefois rien n'y faisait.
Un jour, j'ai profité d'une offre sur Ebay et j'ai commandé de l'ECC registry ... je n'ai jamais eu d'erreur de ce genre par la suite, je ne pense pas que c'était juste une "impression".
Ceci étant, mon nas pro est non-ECC et mes nas perso (une bonne dizaine) sont non-ECC et je n'ai jamais eu de problèmes, donc, je ne sais pas quoi dire (en même temps ... ils ne font pas grand chose, ceci explique cela !)
La mémoire ECC registry est aussi très necéssaire sur des machines ayant une structure compliqué, un pool qui contient un an de MV sauvegardées tous les jours représente une structure complexe et représente réellement une taille gigantesque.
Donc, je ne sais pas quoi dire, je ne peux dire que l'ECC est obligatoire, mais je ne peux pas dire non plus qu'elle est inutile.
J'ai trouvé ceci sur le site durindel.fr/informatique/zfs-presentation-philosophie-vocabulaire
Ce que l’on peut quand même conclure de ce point c’est que plus il y a de RAM et plus ZFS fonctionne mieux. On voit également rapidement que la RAM peut être un point critique, en effet autant l’intégrité des données est assurée sur les disques, autant en cas de corruption en RAM, ZFS ne voit rien et peut écrire une donnée corrompue => C’est pour cela que la RAM ECC (et donc carte mère la gérant et processeur adapté) sont conseillés pour une sécurité maximale des données.
Le risque est faible mais non nul d’avoir des données corrompues suite à une erreur en RAM et encore plus faible, mais toujours non nul de perdre le pool de données complet en cas de corruption en RAM suivie d’écriture si ces données concernent la structure du pool lui-même.
Le risque est faible mais à priori plus important que sur les systèmes de fichiers classiques car la RAM est bien plus utilisée, notamment en cache d’écriture. A vous de choisir de faire avec ou non.
Pour ma part, j’ai jugé ce risque acceptable et ai choisi de la RAM standard pour mon premier NAS, testée toutefois pendant 36h consécutives avec MemTest86, aucune erreur n’étant acceptable.

Concernant un backup d'un tel volume : il a un coût assez important.
la réponse n'est pas valable
On va imaginer une situation, votre nas démarre, mais plus de pool (impossible à monter !), malgré le forum et toute les bonnes volonté, rien n'y fait ... que faites vous ? imaginez la situation ... plus rien n'est accessible !!!
Je vais passer pour un gros parano (ce que j'assume), je conçois mon installation pour résister au pire, c'est à dire qu'il me faudra plusieurs dizaines de minutes et être consentieux pour détruire toutes mon installation (je dis pas avec un marteau mais par commandes webgui ou ligne de commandes ... avec un seul pool je peux le faire en quelques secondes:
zpool destroy monpool; zpool create -f newpool /dev/da0 /dev/da1 /dev/da2 /dev/da3 sur un raidz3 et le "bouillon de 11 heures" fait son effet !
imaginons aussi une alimentation qui grille 4 ou 8 disques d'un coup (car on est bien d'accord qu'il faudra de bonnes alimentations, hein ?, des avec régulation du courant de sortie (les alims qui pèsent rien et à pas cher c'est bien, mais chez les autres !)


A l'origine il était composé de 6 disques de 2 To (RAID-Z2 toujours) mais le manque de place (volume de données) m'a obligé à augmenter dans un premier temps la taille des disques puis leur nombre dans le Pool car les disques plus gros sont toujours hors de prix ...

La multiplication des disques utiles par rapport à ceux de "redondance/parité" m'a permit aussi a l'époque de diminuer le cout du Pool et c'est pour cela que j'avais rapidement choisi un gros Pool 10 disques RAID-Z2 puis 18 :

1. Je souhaitais éviter d'avoir plusieurs Pools pour ne pas multiplier l'ensemble des disques de redondances (taille du boitier et nombre de SATA disponibles)
oui, c'est vrai

2. Je souhaitais aussi éviter de multiplier le nombre des partages : quand je cherche un fichier je n'ai a le chercher que dans un seul partage et pas dans les x partages des x Pools créés
non, là c'est faux !
Les liens symboliques permettent de mettre les fichiers oû on en a envie, perso, j'utilise mc et çà va très vite.
Donc tous les fichiers peuvent très bien être dans un seul répertoire, la recherche d'un film se fera dans cet espace, en revanche, la lecture du film se fera ailleurs.
Vous pouvez très bien avoir:
/pool/films/film1 (qui est sur le pool dans ce dataset)
/pool/films/film2 (qui est un lien pointant vers un répertoire monté en NFS)
Il faut juste prendre le soin de copier le film2 là oû il faut, ensuite faire le lien par la commande ln -s ou par mc ou autre (en gui)

J'ai passé un peu de temps pour faire un exemple:
(j'ai mis un No au début des fichiers, car çà permet de s'y retrouver et de faire de la complétion rapidement)
nas198: na4f_test_liens_nfs# ls -1
0002.nom_A.avi
0003.nom_B.avi
0004.nom_ABC.avi
0005.nom_truc.avi
0008.nom_bidule.avi
0009.nom_xyz.avi
0011.nom_machin.avi
0029.nom_toto.avi
0034.nom_titi.avi
0035.nom_chose.avi
Très franchement, peut-on dire d'oû proviennent ces fichiers ?

... et bien, si on regarde de plus près:
nas198: na4f_test_liens_nfs# ls -lh
total 21
-rwxrwxrwx 1 root wheel 12B Mar 10 21:08 0002.nom_A.avi
-rwxrwxrwx 1 root wheel 27B Mar 10 21:08 0003.nom_B.avi
lrwxrwxrwx 1 root wheel 26B Mar 10 20:46 0004.nom_ABC.avi -> /mnt/n191/0004.nom_ABC.avi
lrwxrwxrwx 1 root wheel 27B Mar 10 20:46 0005.nom_truc.avi -> /mnt/n191/0005.nom_truc.avi
-rwxrwxrwx 1 root wheel 34B Mar 10 21:08 0008.nom_bidule.avi
lrwxrwxrwx 1 root wheel 26B Mar 10 20:46 0009.nom_xyz.avi -> /mnt/n192/0009.nom_xyz.avi
lrwxrwxrwx 1 root wheel 29B Mar 10 20:46 0011.nom_machin.avi -> /mnt/n191/0011.nom_machin.avi
lrwxrwxrwx 1 root wheel 27B Mar 10 20:46 0029.nom_toto.avi -> /mnt/n192/0029.nom_toto.avi
lrwxrwxrwx 1 root wheel 27B Mar 10 20:46 0034.nom_titi.avi -> /mnt/n192/0034.nom_titi.avi
-rwxrwxrwx 1 root wheel 59B Mar 10 21:11 0035.nom_chose.avi
là on voit l'origine, mais on n'en sait pas encore assez, alors, un petit "mount" nous donnera:
nas198: na4f_test_liens_nfs# mount | grep mnt
192.168.1.191:/pool0/n191 on /mnt/n191 (nfs)
192.168.1.192:/pool0/n192 on /mnt/n192 (nfs)
et bien ces fichiers proviennent de deux nas4free embedded en ZFS (mais ils pourraient être en UFS ou autre), et ils sont montés sur un nas4free, j'ai fais les liens avec mc, mais ils pourraient être fait automatiquement par un script

Dans l'exemple ci-dessus, on peut imaginer que les fichiers récents sont immédiatement stockés sur votre machine principale, et quand vous aurez le temps, vous déplacez les fichier sur des parties nfs (l'avantage c'est que ces parties peuvent être arrêtées, çà ne gène pas la machine principale), vu l'utilisation des fichiers, je dirai qu'un rasbperry pi3 ferait l'affaire (4 usb), et (à confirmer), chaque usn peut être sur un hub usb auto-alimenté qui peut fournir 4 usb, ce qui donne 12 usb par rpi pi3. (les rpi pi3 ou carte fanless plus puissante peuvent être en brtfs), ou tout simplement en zfs, le partage nfs peut être passer en read-only (et les copies seront opérationnelles par un scp ou un rsync en mode déplacement (à bien utiliser ! avec l'option remove-source-files)

3. Connaissant les besoins grandissants et le fait que le nombre de disques d'un Pool serait figé au départ j'ai préféré partir d'emblée sur un gros Pool (cela répondait aux deux premiers points). Même si je savais qu'il faudrait changer tous les disques pour étendre la taille globale du Pool car j'avais déjà été limité sur une précédente config avec moins de disques : trop cher de monter des disques de plus grandes tailles (inondations à Taïwan il me semble)
oui (même cela a peut-être été un prétexte)

A l'époque et d'après mes recherches et connaissances je n'avais pas trouvé de solutions plus économiques car cela permettait et me permet encore de prendre des disques avec un meilleur prix par Go.
vrai

Vu l'utilisation j'utilise du Sata 5500-6000 tours ce qui est bien suffisant pour saturer la bande passante Ethernet (même en cas de transferts de fichiers) cela consomme moins et fait moins de bruit que du 7200 ou du 10K.

Pour des disques plus gros je suis d'accord mais cela a encore une fois un surcoût au Go (ce sont en général des disques assez chers car pas encore courants), d'autant que dans cette config il est difficile de diminuer le nombre de disques du Pool, je vais regarder du côté de btrfs mais j'avoue que le fait de savoir se débrouiller déjà un minimum avec nas4free reste un confort et les besoins grandissent plus vite que les capacités/coûts des disques, c'est pourquoi je maintien le nombre de disques dans le Pool.

J'ai conscience que tout n'est pas parfait mais l'usage n'est pas industriel non plus. A l'époque la robustesse affichée de ZFS par certains d'entre vous m'avais convaincu de prendre ces risques "mesurés" et bien sûr dans les premiers mois les données étaient backupées ailleurs.
On n'a jamais d'installation parfaite, çà n'existe pas, elle est souvent "au mieux", dans votre cas, il y a eu beaucoup de réflexion et les choix sont bons, je suis juste sceptique sur la taille du pool qui me paraît un peu énorme avec du matériel "léger" non-ECC (même si ce n'est pas pour utilisation industrielle, la conception est là et ne change pas du tout les données du problème)

Pour la carte mère en cas de panne je peux patienter le temps d'en racheter une ou en trouver une d'occasion/neuve en prévision d'une panne.
Dans ce cas c'est bien


Donc pour finir:
Pas de soucis pour utliser une machine non-ECC, mais:
- pas de pool volumineux
- pas de non sauvegarde (rien que l'idée m’effraie à un point ... même pas imaginable !!!)
en plus
le SATA, ce n'est pas performant du tout, une carte SAS permettra toutefois un peu de "récupérer" les faiblesses.

Sachant cette fois l'utilisation que vous allez en faire, je ferais:
- une machine principale (avec un pool de 2 disques: miroir) pour du transit de fichiers
- des machines secondaire en NFS (on ajoute une deuxième machine quand la première est pleine)
une machine secondaire:
* disques SATA (source)
* disques USB (double) qui sont généralement arrêtés (allumés juste pour un rsync)
* carte mère fanless (on trouve des cartes pour 50 ou 65 euros en premier prix: ).
L'avantage pour vous serait d'avoir la moitié des disques arrêtés d'office et d'avoir juste le disque qui est en lecture qui sera sollicité. En plus avec le partage NFS en ro ... c'est la zenitude

Je dirais qu'en faisant les choses bien: 3 petites cartes mères suffisent:
2 disques (machine principale)
4 à 8 disques sur une machine secondaire, et quand la machine est pleine ... une autre s'ajoute avec 2 disques (source+backup), puis les disques augmentent.

Cette phrase:
certains d'entre vous m'avais convaincu de prendre ces risques "mesurés" et bien sûr dans les premiers mois les données étaient backupées ailleurs.
1) aujourd'hui certaines personnes sont toujours convaincu de ZFS, mais sont aussi devenues plus "sage"
... pour ma part, si mon objectif de départ était de me faire plaisir et de tout mettre à bloc en ZFS (Zcache,Zlog), aujourd'hui, je suis sur "une structure en rapport directe avec mes besoins"
2) "... les données étaient backupées ailleurs" çà c'est important, car çà veut dire que la taille du pool fait que l'on ne backup plus !!! X 1000
le problème est surtout là => la taille du pool impose un non respect des règles de bases (car si le backup était là, pas de soucis pour faire votre gros pool ... sauf que ... lorsque le backup est tout seul ... et bien, il n'y a plus de backup du tout ! )

Désolé pour être "rabat-joie" ... je m'adresse à une personne "ami" et c'est quelquefois nécessaire ... un homme prévenu en vaut deux