Reprise du message précédent :

 
j'ai expliqué dès le début pourquoi le mirroring lvm était pourrit
 

 
non, je cherche à avoir des données mixées en raid1 et raid 0 sur 2 disques tout en étant pas emmerdé par des tailles de volumes fixes.
mais comme t'as des gros soucis de lecture ...

 
Pardon, en effet.
 
Donc, tu veux avoir UNE PARTIE de tes données sur du RAID 1 pour la sécurité, sur un truc super pourri qui te laisse 0% de chances de récupérer quoi que ce soit dès que tu auras une merde [:rofl:]

j'ai balancé cette idée alternative avec LVM pour le fun, mais toi tu le prends ultra sérieusement depuis le début    
 
et t'en démords pas, tu vas sans doute même tenter de prouver que j'ai déjà passé mon système là dessus c'est ça ?

Non, mais si t'as vraiment ce besoin de base (Un matrix raid ou tu puisses distribuer le ratio entre le RAID0 et le RAID1), y'a des chances que LVM convienne en fait.
 
A priori le seul truc qui te posait problème sur le mirroring de LVM c'était l'histoire du log, mais tu n'es pas obligé d'avoir un disque supplémentaire pour le stocker.
 
Tu peux utiliser lors de la création de ton miroir les options -mirrorlog mirrored et -alloc anywhere.
 
Cela créera un mirror log d'environ 4Mo répliqué sur tes deux disques, ce qui garantira l'intégralité de ton miroir en cas d'incident.
 
 
Si tu attends que ZFS soit patché pour répondre à ton besoin, malheureusement tu attendras longtemps. Il y a toute une tripotée de patchs qui ont été développés (par exemple l'augmentation / réduction du nombre de disques d'un zpool), mais qui n'ont jamais été mis en place.
 
Et même si ca venait à arriver sur ZFS, le temps que ca arrive ensuite sur *BSD et Linux ...
 
Pareil pour Btrfs, on en est loin ...

je suis au courant de l'option mirrorlog
si il doit écrire dans ce petit extent à chaque écriture dans un extent ça doit démolir les perfs en écriture, donc ça me motive pas trop
si ça se trouve une clef usb pourrait suffir mais ça me bote pas
 
ce vers quoi je me dirige c'est faire sur chaque disque une partition de 50G et une de 1,9T
et avec mdadm celle de 50G en raid0, et celle de 1,9T en raid1  
et j'integre ces deux volumes physique au lvm
 
je dois le faire depuis un moment, mais j'ai pas encore trouvé le courage, surtout que c'est super long pour déplacer les données et les synchroniser, et que c'est pas vital
 
l'idéal serait biensur la redondance par fichier ou par dossier, mais on en est loin ...

Je ne pourrais pas te donner l'impact du mirrorlog vu que c'est une situation que je n'ai jamais benchée. Sur du mdam, en tunant finement la taille du log, on peut obtenir une perte de perfs très faible, invisible en usage NAS.
 
Tu as raison de ne pas vouloir utiliser de clé USB. Cela suffirait très probablement pour la taille et la vitesse si tu utilises une clé rapide, mais la mémoire flash n'est pas adaptée pour de l'écriture continue, et les algos de wear levelling sur les clés USB ne sont pas au niveau de ceux présents sur les SSD par exemple.
 
Ta solution finale est effectivement la plus éprouvée.
 
Après, que dire ...  
 
D'un côté tu as les FS natifs à Linux, qui vont galérer à offrir un truc aussi unifié que ZFS, parce que Linus Torvalds veut logiquement qu'ils se basent sur les couches déja existantes (LVM, VFS, mdadm, les couches de cryptage, etc). Souci, c'est que du coup les fonctionnalités qu'on attend d'un FS actuel (raid sans write hole par exemple) seront assez chaudes à mettre en place.
 
L'empilement de tout ca permet une souplesse inégalée, mais quid du support quand une des couches foire ... Je me tape de temps a autre des incidents liés à ca dans le cadre du boulot, et c'est très mal voire pas documenté du tout.
 
Ce sera compliqué à la fois techniquement, mais aussi politiquement, de voir émerger Btrfs en "vrai concurrent" de ZFS.
 
Du côté ZFS, avec l'abandon de la distrib "grand public" de Solaris, je pense que le FS ne va continuer à évoluer que dans le sens "besoins pro", et tous les patchs qui pourraient intéresser les particuliers vont passer à la trappe.
 
Du coup, j'ai l'impression que c'est du côté Microsoft (par exemple avec le système de stockage adopté sur WHS 2011) qu'on va voir apparaitre un FS mieux adapté aux besoins de stockage d'un particulier.

oracle pousse pourtant btrfs, ils ont poussé le dev à sortir un fsck pour btrfs pour pouvoir mettre btrfs dans leur distro dédié à oracle sur linux.
 
ubuntu à déjà intégré btrfs dans son installeur
 
 
pour mdadm il me semblait que les métadatas étaient stockées au niveau des "strippes", mais si c'est pas le cas, alors c'est sur que ça sera pas pire que le mirrorlog de lvm
je pensais que l'equivalent du mirrolog de mdadm était le bitmap, qui est n'est pas obligatoire sur mdadm

Btrfs est en effet poussé par Oracle (enfin le dev a récemment changé de boite, même s'il continuera a développer btrfs), le souci vient plutôt de l'intégration de certaines fonctionnalités genre le RAID.
 
Dans ZFS, la gestion du RAID est incluse directement dans le système de fichiers. Mais le dev de btrfs s'est fait rembarrer sur cette approche, qui conduirait à injecter du code redondant dans le kernel (le mirrorring de LVM, celui de mdadm, celui de btrfs, etc ...).
 
Que btrfs soit poussé est une chose, que des accords soient trouvés pour débloquer la possibilité d'implémenter certaines fonctionnalités en est une autre.

btrfs est pourtant censé permettre de se passer de LVM , mdadm, ext4, ça me parait bizarre
 
btrfs supporte déjà raid1 raid0 et raid10
manque le mix raid1 et raid0
 
 
https://btrfs.wiki.kernel.org/index [...] le_Devices
 
edit: ok tu as confondu zfs et btrfs

Non non, je ne me suis pas trompé.
 
L'implémentation du RAID de base (raid 0,1 et dérivés) a fait l'objet de vives discussions sur les mailing lists.
 
Au final c'est passé, suite entre autres au fait que les mécanismes  d'allocation du raid1 sur btrfs sont très spécifiques (le raid ne se fait pas au niveau des devices, mais par extent, avec du thin provisionning).
 
Pour le raid5/6, ca discute un peu plus. Exemple : http://lwn.net/Articles/463575/
 
En résumé, y'a eu plusieurs patchs de proposés pour rajouter le support du raid5/6 à Btrfs, mais la façon dont ce sera mis en place est encore loin d'être décidée. Soit c'est poussé dans le code de btrfs => fête du slip, on autorise tous les FS a réinventer le RAID à leur sauce.
 
Soit on place du code générique à un endroit (dans mon lien, un développeur proposait exofs). Si c'est la solution qui est décidée, cela veut dire qu'il faudra aussi y remettre tout le code RAID0 et RAID1 de btrfs, par souci de cohérence.
 
Y'a une vision assez claire de ce qu'on veut obtenir au final, mais chaque fonctionnalité prend pas mal de temps avant d'être finalement disponible.

 
(noob inside)
 
Voilà quelques années que j'ai un freenas (pour une utilisation domestique) qui tourne avec 2 HDD de 2 To chacun en raidz.
En parcourant ce topic, je commence à comprendre que c'était pas forcément le choix le plus judicieux mais jusqu'à présent, la bête fait son taf sans broncher  
 
Mon raidz commence à saturer, et je songe investir dans 2 HDD de 4 To. Quel serait la meilleure solution (pas trop hard à mettre en oeuvre tant qu'à faire) pour avoir un volume qui comprenne une grappe raidz de 2 To et une grappe raidz de 4 To pour faire un volume global de 6 To ?
Serait-ce possible sous freenas ? Sous nas4free ?
 
 

Ca a l'air d'être ce qu'il ya de plus facile, créer un raid avec les deux nouveau disques et l'ajouter au pool existant.
cf la réponse de 2011 :  [je pense qu'il voulait parler d'un zpool, et non d'un "vpool"]

Effectivement c'est ce post auquel je faisais référence, et bien évidemment j'ai accès mes recherches sur le vpool et ça ne donnait rien :\
J'vais voir ça du côté du zpool.

Merci !

Edit : Voilà qui semble pas mal

Question noob (si topic pas mort...)
en RaidZ, il y a 1 disque de parité... donc taille = Ndisque_min - 1
Mais il doit bien y avoir un moment ou le disque de parité ne peut encaisser le N
Si 100 disk de 1T, size=99T... mais est ce que le 1To est suffisan tpour encaisser la parité ?? et donc rester proof a la casse de 1 disque ?

Euh, t'as du RaidZ de toutes les formes.
Et la parité n'est pas fixe, ca va de N-1 a N/2, c'est une sorte de TOC a bit de parité : si les blocs écrits sont larges dans le meilleur des cas, oui t'es a N-1, dans le pire des cas, avec des données qui prennent toutes 1 bloc, t'es a N/2 (raid 1)
En ZFS on réfléchis pas disques mais données.
Après t'as le RaidZ2 et le RaidZ3. Autres questions ?

Dans la théorie, je pense qu'un raid Z à parité simple sur 100 disques marche, dans la pratique c'est une idée abominable?
 

Dans la pratique, t'utilise pas du raidz

D'autant que par vdev, avec des disques formaté en 4Ko (advanced format), on limite en
-> raidZ : 9 disques
-> raidz2 : 10 disques
-> raidz3 : 11 disques

Le raidZ est utilisé pour du stockage en backend, genre pour les serveurs de production vidéo,  la basse résolution des archives importantes mais peu utilisées sont stockées dessus ; la haute résolution étant sur LTO4.

Désolé je ne pige pas tout.... noob zfs
augur1 : tu parles de limitation, mais c'est du "best practice" ou limitation réèlle?
MysterieuseX : troll Si je te suis, ca veut dire qu au delà de 3 (donc equivalent 2 "utilisables" ) il n'est pas garanti de récupérer ses data (depend du type de data ?) ?
 

Pour avoir de bonnes perf, en disque Advanced Format (4ko)  
Cf : http://forum.setiaddicted.com/view [...] ef2#p99519
 
++

Ce post date de 2011, t'es passé à 8 en Raidz2
Dans les tuto tu cites openBSD mais les BSD ne sont pas dans ta liste d'OS

Plein d'info merci.

Le stockage, c'est ce que je veux faire, je ne cherche pas la perfo, mais la bibliothèque (donc extensible sans tout casser) proof aux incendis...
J'ai déjà prévu le backup simple (snapshot vers une autre ville), maintenant je cherche la config local...
Je ne sais pas trop comment trouver le compromis, simple à étendre (donc grappe pas trop grosse pour changer tous les disque en "meme temps" ) mais avoir assez d'espace au départ, avec le minimum safe (parce que le backup c'est bien, mais c'est en dernier recours... c'est loin et pas forcement update -1/jour-), sans pour autant me retrouver avec 30 cartes SATA à ajouter...

PS: 96Go de RAM tu rigoles pas toi...

sub.mesa wrote:
As i understand, the performance issues with 4K disks isn’t just partition alignment, but also an issue with RAID-Z’s variable stripe size.
RAID-Z basically works to spread the 128KiB recordsizie upon on its data disks. That would lead to a formula like:
128KiB / (nr_of_drives – parity_drives) = maximum (default) variable stripe size
Let’s do some examples:
3-disk RAID-Z = 128KiB / 2 = 64KiB = good
4-disk RAID-Z = 128KiB / 3 = ~43KiB = BAD!
5-disk RAID-Z = 128KiB / 4 = 32KiB = good
9-disk RAID-Z = 128KiB / 8 = 16KiB = good
4-disk RAID-Z2 = 128KiB / 2 = 64KiB = good
5-disk RAID-Z2 = 128KiB / 3 = ~43KiB = BAD!
6-disk RAID-Z2 = 128KiB / 4 = 32KiB = good
10-disk RAID-Z2 = 128KiB / 8 = 16KiB = good

Erreur, j'edite : pas de 8 disques en raidz2.
 
Post de 2011 édité en octobre 2012, seuls les ssd ne sont pas à jours.
 
++

Pour formuler ce qu'il y a ci-dessus autrement, le nombre de disques de données "effectifs" devrait être une puissance de deux. Donc 5 disques équivalent raid 5, quatre disques effectifs, c'est bon.
 
Encore faut-il quantifier ce "problème" de performance..
 

Moi ? Troller du ZFS avec que je tourne sur ZFSonLinux avec des kernel custom et que j'ai un backend lustre ? o_O
 
Pour info :
 
San "homemade" 4 SP :  
E5-2637 x2  
SuperMicro X9DR3-F  
512Go Micron RDIMM DDR3 PC1600  
2xLSI SAS 9201-16i + firmware IT  
FusionIO Drive2 SLC 600GB (L2ARC)  
Plextor M5P 256G x2 (Système mirror)  
STEC ZeusRam dualport x2 (ZIL)  
Cheetah 15k.7 600G x26  
ATTO FC-82EN  
Boitier iStarUSA E5M26 + alim 1500watts.  
NexentaStor Gentoo (custom) + Lustre

le doute sur le troll était pour :

En fait ma question est :
"est on sure de retrouver toutes ces data sur la défaillance d'un disque avec 1 disque de parité seulement quelque soit le nombre de disques [I]effectifs[/I] ?"
Je ne parle pas :
- du fait que c'est long et que pendant la reconstruction tout autre dégradation entraine la perte complète du pool etc...
- des performances (que je ne note, donc effectif = 2^x)
Je cherche simplement la limite de la notion de parité pour la reconstruction (avec 1 ou 2 ou plus de disque d'ailleurs)

Je prends pour exemple les newsgroup binaire, avec fichier PAR. Suivant le volume de PAR dispo on peut reconstruire + ou - de fichier perdu mais il y a une limite.. donc là je me pose la question de la limite...
Après je comprends que dans les "best pratice" on ne doit pas atteindre cette limite puisqu'on limitera le nombre de disque par zdev pour de raison pratiques, perfo... Mais cette limite doit bien exister et je n'en trouve mention nul part

 
Ben dans la pratique le raidz est très contraignant oui, mieux vaut calculer ta volumétrie pour monter des zpool vdev mirror/strip et bien configurer son hotspare avec des scripts qui vont bien pour le remplacement/alerte, que d'utiliser du raidz. Sachant qu'un fail sur un volume raidz c'est offline directement, remplacement du disque fautif et 4 a 5 heures pour des volumes "moyen" de récupération/rebuild, si t'es en prod avec une HA demandée, c'est mort. Y'a pas de solutions miracle pour la HA.
Pour un particulier ou de la sauvegarde (bien que sur disque dur je trouve ça bof la sauvegarde > demande d'avoir dans tout les cas les données redondées quelque part en plus du volume de prod, soit dans tout les cas : volume de prod, sauvegarde 1 et sauvegarde géographiquement séparée 2) .
Quand tu commence a parler resilience et performance, tu te rend compte que le raidZ/2/3 c'est pas une si bonne idée et que ça n'a d'intérêt que si ton workflow ne fait que lire les données sans jamais les écrire (enfin, juste 1 fois).
Si ton domaine n'a pas besoin d'écrire sur les disques en permanence ni de HA, que t'as le temps pour reconstruire tes grappes, go for it, autrement, passe ton chemin.

OK, Je vois.
Donc je précise :
- c'est du particulier (déjà ca fixe pas mal de chose)
=> donc pas de contrainte de HA
- il y a 2 cas.

Cas 1 : bibliothèque
- c'est une archive de media (video, music, document...)
=> 90% d'accès lecture, peu d'écriture (sauf au début pour le remplissage)
=> partage WebDAV (worldwide/HTTPS) pour une 20aines de personnes... donc je ne pense que le perf soient important (plus limité par la connexion internet que par le serveur je pense).

Cas 2 : le locals
- chaque users à un local dessus... (toujours en WebDAV/HTTPS)
- avec les snapshot/H (pour le moment ils se contenteront de cela).
=> là je ne sais pas trop les contraintes.

Enfin tout ceci est répliqué à l'extérieur 2 fois pour le cas 1 (1 backup + 1 mise à dispo non temps réel) et 1 fois pour le cas 2.
réplique = snapshot envoyer par ssh sur un simple stripped.

Pourquoi ZFS :
- les snapshot faciles
- les OS sont en FreeBSD (serveur/réplique(s))
- les quotas faciles
- ajout simple d'une grappe

Pourquoi WebDAV :
- supporté par Windows (lecteur réseau, 7 et 8)/linux (de toute sorte)/FreeBSD
- gestion des droits assez simple
- de toute facon il y a dejà un serveur Web qui tourne...
- nativement worldwide
- moyen simple de crypter (OK pour la sécu il y a mieux, mais pour le moment ca ira)
=> pas de samba (trop lourd à long terme, j'en ai marre, je teste autre chose )
=> pas de VPN (trop lourd à gérer avec crypto pour les différents poste/site/box, IPv4/6...)
=> donc plus simple.

En terme de perf locale, il doit simplement tenir en simultané :
- le home de 3 personnes lambda bureautique (pas de dev furieux, geek et autre mangeur de perf )
- 2 flux video HD
- 2 flux Audio 320Kps 2 canaux
En externe (simultané toujours) :
- site web de papa maman...
- 1 flux Audio 320Kps 2 canaux.

=> pas de P2P, torrent et autre bruit de fond.
Je ne pense pas que ce soit très impactant

PS :
concernant la sauvegarde sur disque... tu penses a quoi ?
- optique => pas viable dans le temps + chiant à gerer
- usb => ca revient à du disque
- bande... c'est plus chiant (voire long) à gérer...
pour moi le disque c'est qu'il y a de + simple, + rapide, + souple...
Dans tous les cas il faut multiplier les locaux physique (vol, inondation, incendie...)

plus de conseil

Quel volume de stockage ?  
 
Avec des disques de 2 To : tu peux faire du RaidZ ; avec des 3 To ou 4 To mieux vaut faire du RaidZ2
 
Il te faut une carte HBA, genre LSI ou IBM m1015 flashé en firmware IT de Lsi... et de la mémoire ECC, genre 8 Go minimum.
 
++

Ben je pensais 2Tx5 en RaidZ sur une carte+ram+proco avec ECC bien sur.
Pour le volume de ram je pensais partir sur 2x4G ou 2x8G suivant prix du 1er tuple.

Pour la backup (doublé donc, accès en lecture seule, sauf pour mettre à jour), je pensais à un simple disque de 2x2To strippé dans un bete nas sous Nas4free (1Gram de base donc).
Mais comme ZFS contrôle de manière assez bas niveau... je me demande si il n'y as pas une hérésie à le faire ?

Pour en revenir à la question initiale...
5x2T garanti de récupérer tout sur 1 défaillance, alors que la parité laisserait penser que seuls 3x2T peut le faire (puisque ca peut aller N/2) ou alors il y a des calculs savants de proba sur le type d'info stockée ? qui dit N-1 est suffisant ?

 
Désolé pour vpool, j'étais en train de découvrir ZFS à l'époque. Maintenant ça fait un an que j'ai une zpool comprenant un vdev de 19 disques de 2To en RAIDZ3.

Il faut que tu lises un peu sur les bases du RAID là, enfin meme pas, c'est le concept de parité, utile aussi pour comprendre le PAR/PAR2. C'est des maths, en gros on prend X disques ou blocs de données, on applique une formule mathématique dessus qui produit 1 disque/bloc quel que soit la valeur de X (ou 2 pour du RAIDZ2/RAID6, 3 pour du RAIDZ3), et on peut par un calcul mathématique inverse retrouver n'importe quel bloc manquant grace à cette parité. Dans le cas du RAID5/6/RAIDZ, ça veut aussi dire que si on perd + de disques qu'il n'existe de "disque de parité" (qui n'existent en fait pas, la parité est répartie sur tous les disques), plus aucune donnée n'est lisible. Autrement dit le RAID5 et le RAIDZ1 sont morts aujourd'hui, pas assez fiables.

Je pense que par RAIDZ il entendait RAIDZ1, les deux étant équivalents.

 
En pratique il n'y a aucun problème de performance (ou à peine mesurable), par contre on y perd en capacité si on ne respecte pas ça. D'où mon RAIDZ3 de 19 disques => 128K/(19-3)=8K=2*4K.

!!!???!!!!  

En RaidZ (équivalent Raid 5), avec des disques en Advanced Format (4k) le nombre de disque recommandé est : 3, 5, max 9

En RaidZ2 (équivalent Raid 6), avec des disques en Advanced Format (4k) le nombre de disque recommandé est : 4, 6, max 10

En RaidZ2 (équivalent Raid 7), avec des disques en Advanced Format (4k) le nombre de disque recommandé est : 7, max 11

...

J'ai discuté avec pas mal de gens et lu les arguments de chacun (sub.mesa y compris), notamment sur hardforum, fait moi-même les calculs, testé plusieurs configurations, et il n'y a aucun problème avec mon setup, je ne suis pas le seul à l'utiliser d'ailleurs. Je n'ai pas non plus respecté d'autres recommandations que tu donnes, par exemple il y a des disques de différentes marques, et différentes vitesses !

Privé ou prod ? Environnement ? Charge typique ?
On va dire que c'est pas commun et pas un exemple a suivre en prod.

ça veut dire quoi production ? On n'est pas sur hardware-pro.fr si ? C'est un serveur de stockage perso, charge minimale, il est même éteint 23h/24.
 
Un ptit bonnie++ donne du 400Mo/s.

Il n'y a pas de problème tant qu'il n'y en a pas : les recommandations ont été suggérées pour d'un coté éviter les problèmes et de l'autre pour pouvoir intervenir rapidement en cas de problème.
 
Le truc avec 19 disques, c'est la durée que prend le scrub + la réparation & perte de performance lors de celle ci.
... t'aurais juste pu indiquer dans le même post que ton serveur est en fait utiliser seulement 1h / jour.

 
Comme dit Augure, scrub + perte de perfo en production c'est rédhibitoire, quand t'as une latence des quelques secondes sur une requête bidon, t'évite (sans compter la réparation etc ...) en privé, y'a pas franchement de soucis.

Je connais le principe de "parité" detection ou detection+reconstruction
Mais qqsoit l'algo utilisé, il y a des limites :
- combien de faute sont réparables dans un "mot"
- taille du "mot"
=> résultat : un volume de redondance.

Donc, suivant le volume de mot, il y un volume de redondance...

En Raid de base il y a des disk dédiés, en Zfs c'est répartis, mais ca ne change pas le blem....

Je comprends que RaidZx indique à Zfs de doubler la redondance (2 fautes ?), mais ca ne change pas qu'il y a bien un max théorique de data (a priori proportionnel, et encore ) recouvrable suivant l'espace alloué à la redondance...

Sur une barrette de RAM, c'est simple, la barrette fait xGo, l'espace ECC est de yGo.
Sur Zfs, ex en RaidZ1, l'équivalent d'un disque est utilisé pour la redondance (je nomme CRC), mais le nombre de disque data MAX
mais raisonnement pour un Raid de base.

Ou alors, comme c'est distribué, c'est simplement l'espace disque qui diminuera plus vite, DATA+CRC au lieu de DATA, le "x" de RaidZx indiquant à Zfs le nombre de faute toléré (mais j'ai du mal à imaginer la répartition des data/CRC autorisant la perte de 2 disques en même temps ^^, ca doit être très compliqué à suivre) exemple :
- RaidZ2
- 12 disques data
- 2 disques spare
=> en fait on ne peut remplir que 11,6 dique au lieu de 12 ; car le max est de 10, donc 20% de CRC

Mais dans ce cas, ca voudrait dire que dans cet exemple :
- RaidZ2
- 4 disques data
- 2 disques spare
=> en fait 1 seul disque de spare suffit (20%*4=0.8) (on n'est proof que pour la perte de 1 hdd, mais 2 clusters non )

Cela dit les Max donnés par augur1 sont recommandés...

Dans ton dernier liens les valeurs ne sont pas les mêmes...

Les 2 liens ne collent pas...
RAIDZ1@7 ne colle pas à la formule
RAIDZ2@4 c'est comme faire 2 mirror (donc on passe), c'est comme RaidZ1@2...

Si on ne considère que la formule pour 4K :

En effet, après le résultat est <@4K...
(une réponse à ma question ; mais alors :
- il reste le cas du 2eme exemple : RaidZ2 avec 1 disque de redondance
- si on raisonne avec 512, ca veut dire qu'on peut mettre plus de disque , mais avec des perf proche d'un 286 )
)
Si on enlève les cas "idiots" en fait de bêtes mirror :

Dans aucun on ne trouve les max du lien 2, en revanche les min oui.
Donc tes info de max sont plutot orientés perf à la reconstruction, tu élimines les 2 derniers cas.

Donc la config de asmomo est correcte, mais il va en chier pour le reconstruire...

D'après ce que tu écris tu n'as pas vraiment compris le principe de la parité. Il n'y a pas de limite au nombre de blocs/disques protégés (en théorie, après en pratique il y en a surement une mais venant d'ailleurs que des maths). Il y a bien sur une limite aux erreurs que tu peux réparer, si tu as 2 disques de 2To de parité (quel que soit le nombre total de disques), et que tu as plus de 4To de données de corrompues/illisibles, forcément ça n'est pas récupérable.
 
RAID "normal" ne veut rien dire (RAID n'est pas un standard), en tout cas en RAID5 et RAID6, la parité est bien répartie sur tous les disques, pour avoir un disque de parité dédié il faut faire du RAID3 ou du RAID4, des modes assez rares.
 
Ensuite pour les calculs tout est basé sur les blocs ZFS qui font 128Kio. Pour ne rien perdre en espace et pour avoir des écritures bien réparties sur tous les disques, il faut que le nombre de disques de données soit un diviseur de 128Kio donnant un résultat entier et >= à 4, donc 1/2/4/8/16/32. Avec des disques 512o zapper/doubler un secteur par ci par là avait moins d'importance qu'avec des secteurs de 4Ko, mais le nombre optimum était le même.
 
Enfin, un RAIDZ2 de 4 disques a du sens par rapport à un miroir, car un miroir de 4 disques c'est comme du RAID10, càd un RAID0 de 2 RAID1, si tu perds 2 disques du même RAID1, c'est game over. Avec le RAIDZ2 tu peux perdre 2 disques quelconques.