Reprise du message précédent :
d'ailleurs attention: on peut très facilement ajouter des vdev mais une fois ajoutés on ne peut plus les enlever

oui mais ça nécessite que les machines source soient aussi en ZFS
 
pour mes besoins j'ai trouvé aussi:
zfs-snap-manager: https://github.com/khenderick/zfs-snap-manager
sanoid: https://github.com/jimsalterjrs/sanoid/
 
les deux outils semblent très proches niveau fonctionnalités, je vais essayer zfs-snap-manager d'abord

ouaip m'enfin mdadm en réduction c'est pareil donc c'est kif kif    
faut juste pas l'oublier
d'ailleurs ca va me permettre de passer de 2 vdev raidz de 4*2To à 3vdev histoire de retrouver un peu de place à pas cher

Attention aux nombres de vdev dans un même pool. Un seul vdev qui crashe et toutes les données du pool sont perdues.
 
Pour l'instant, je garde des pools avec 2 vdev (mirrored) dans chaque pool. J'ai des perfs suffisantes (200 Mo/s écriture, 400 Mo/s lecture) et c'est plus safe que 8 disques dans un seul pool.

avec du raidz2 on peut surement monter un peu plus en vdev sans trop de risque.
 
genre 4 ou 5 vdev en raidz2 ça doit être encore correct

Mais faut clairement avoir un gros besoin en perfs pour ce genre de pool. Et j'ai l'impression que la tendance c'est de faire du mirror plutôt que du raidz2 car avec les disques actuels les temps de resilver deviennent extrêmement longs.

le temps de resilver est identique en mirror et en raidz1/2/3 (s'il n'y a pas de limitation CPU, mais à moins de tourner sur un atom ça ne devrait pas être le cas...)
 
La grosse différence pour le resilver c'est qu'en config mirror, à nombre de disque identique, tu as plus de vdev, et donc le resilver d'un seul vdev  affecte moins les performances globales du pool. (et s'il est saturé en accès alors là oui le resilver ira plus vite)

 
up

je dis peut-être une connerie mais il me semble dedup fait grossir virtuellement le pool.
Dans il ne faut pas regarder l'espace utilisé mais l'espace total ou disponible

Je regarderai de ce côté là merci

 
ça ne craint pas plus qu’autre chose  
après c'est un choix  de toute façon  un raid  qu'il soit soft/hard de n'importe quel moyen    c'est pas un backup (dur de convaincre des clients qui le font en prod ... jusqu'au jour ou pouf)  
  c'est juste un moyen de pallier à certaines pannes à chaud  
 
donc après tout dépend des besoins et de la criticité des données dessus  
pour ma part    ça me permet  d'étendre vdev par vdev au fur et a mesure de mes besoin (4*2To raidz  donc 5.x To exploitables  ca laisse le temps de voir venir à bas cout vu le prix des 2To maintenant)  
- c'est cablé en sas externe sur norco 4020  donc je peux chainer des tiroirs disques supplémentaires) -
tout en ayant  une redondance de 3 sur 12  (ok 1 par vdev  m'enfin en ayant des disques non homogènes le risque de panne simultanées est moindre sur 4 disques)  
et puis si ça doit lâcher ... bah j'ai un backup des trucs les plus importants
 
si on suis la logique,  se focaliser sur la tolérance aux pannes n'est pas le bon optique  puisque cela veut dire que souvent on accorde plus d'importance à son raid  qu'a ses backups    
mais je digresse un pneu    
 
 
 

Et comment dans un zpool sont réparties les données entre plusieurs vdev ?

( https://blogs.oracle.com/bonwick/en [...] allocation )
 
en gros ZFS étale les écritures entre les vdev mais si un vdev est moins remplis que les autres il y aura plus d'écritures vers celui-ci

C'est quand même bien fait

du travail est en cours pour gérer "intelligemment" des vdev de vitesse différentes

 
ça tourne super bien pour le moment avec ZoL 0.6.5 sur Debian 8    
 
je me demande combien aurait coûté chez Dell un système identique capable d’accueillir jusqu'à 36 disques  

J'ai un retour sur ce genre de cas : Un pool avec 2 vdev mirror (2x 4 TB + 2x 1 TB). Les deux vdev créés en même temps et donc avec zéro données au départ.
 
Le pool contient maintenant 2.54 TB de données -> Le vdev 2x 1 TB est plein (il reste 9 GB de libre) et n'est pas utilisé pour les nouvelles écritures donc baisse de performances. Je pensais que la répartition serait mieux faite que ça.

ce qui n'est pas incompatible avec le "slightly" énoncé par le du mec de sun d'oracle  
 
sinon c'est clair que ZFS a actuellement de nombreux points faible avec les cas d'utilisation non orthogonaux: tailles de vdev différents, augmentation de la taille des vdev, suppression des vdev, cp --reflink, équilibrage entre les vdev (balance avec btrfs), fragmentation.
 
Btrfs est sensé résoudre tous ces points, les développeurs  de SUN ont préféré implémenter un truc plus simple qui n'a pas autant de fonctionnalités mais qui marche au moins (troll grossier )

 
7 a 8K.
Et pour la  mauvaise répartition sur les vdev, c'est pour ça que dépassé une certaine volumétrie, on met une couche de type lustre.

 
Qu'est-ce que cela ??

un système de fichier distribué

avec tout ? c'est à dire avec le serveur xeon avec 32GB de RAM et aussi les 10 disques de 4TB ? ou juste le boitier sas ou iscsi vide (mais redondé) capable d’accueillir 36 disques ?

8x vDev striped mirrored (16 disques de 2 To)
-> les données écrites sont réparties sur les 16 disques
 
... vous ajouter 4x vDev striped mirrored (8 disques de 2 To)
-> les anciennes données précédemment écrites restent sur les 16 premiers disques
-> les nouvelles données seront écrites sur les 24 disques
 
Panacher en striped mirrored des vDev de capacités différentes ne semblent pas faire bon ménage.

Pas de fonction "balance" sur ZFS ?

non

Bonsoir,
 
Tite question: une technique recommandée pour remplacer un disque en train de mourir dans un raidz2 ?
 
sur mes 6 j'en ai qui meurt (ré-allocation en masse de secteurs ^^) mais j'ai pas la place pour connecter le nouveau.
 

 
honorable pour un green je trouve ^^
 
Du coup, je me disais:
- zpool offline tank /dev/sdc
- zpool detach tank /dev/sdc
- poweroff du serveur, je vire le disque et met le nouveau
- zpool add tank /dev/sdc
- zpool online tank /dev/sdc
 
normalement ca devrait faire le resilvering non?
 
Merci

surtout pas de add !!!!
 
le add va créer un vdev raid-0 en plus du vdev actuel dans ton tank ! et le pire c'est que après tu ne pourras plus l'enlever !
 

https://pthree.org/2012/12/11/zfs-a [...] -resilver/
 
il faut faire un zpool replace tank <ancien> <nouveau>
 
donc ici zpool replace tank sdc sdc

le replace tu le fais quand tu as le nouveau de connecté en simultané or je ne peux pas faire ca  ^^
 
je note pour le add merci

pas du tout ! cf le lien que j'ai donné où il remplace sde par sde (donc pas simulatané!)

effectivement je n'avais pas lu ca, merci

l'idéal est de faire ça:

(extinction, échange des disques, reboot)
 

thanks, it's work

merci bien pour le coup de main

QNAP annonce un NAS basé sur ZFS et freebsd:
http://www.anandtech.com/show/9929 [...] s-and-more
 
Ils supportent la réplication synchrone avec apparemment (en utilisant HAST ? )

petite chose découverte: le fichier arcstat.py qui permet d'avoir la taille max du cache arc et son utilisation.
 
Dispo avec ZoL

Sur ZFS on linux je n'ai pas de remontée par mail de l'état DEGRADED par zed (le daemon zfs)
 
zed par contre me remonte les erreurs I/O
dans le "zpool events" j'ai bien les changements d'état
 
c'est normal ? j'ai un bug ?
 
edit: j'ai bien le "state change" event d'envoyé par zed vers syslog mais pas de mail envoyé par zed
 
ça vient peut-être du ZED_EMAIL_INTERVAL_SECS="3600" mais il me semblait que c'était que pour les même types d'events
 
hors un "statechange" est différent d'un "io error" donc ça ne devrait pas jouer

Par rapport à votre discussion sur la répartition non optimale des données, perso je n'ai pas besoin de grosses perfs donc ça ne me gêne pas, mais sinon il est possible de rééquilibrer en jouant avec les filesystem. Créer un nouveau fs et copier toutes les données dessus (en plusieurs fois si pas assez d'espace libre) permet de tout rééquilibrer.

Tu peut aussi jouer sur les spare, où sur un resilvering et faire un disk round up. Pratique souvent utilisée en clust/bigdata pour équilibrer la charge sur les disques et/où gérer le wear leveling des caches SSD.
Tu peut aussi utiliser des cartes acceleratrices dédiées a ce genre de tâches qui coûtent la peau des fesses. (sun flashfire F20 et son firmware qu'est a moitié fumé, se servent des fonctions raid du procoss pour faire des calculs de charge disques, embed ZFS etc ...) ou une appliance custom basée sur un marvell WAM. (je te laisse googler )

La prochaine version d'Ubuntu supportera ZFS.
Qu'en pensez-vous ?
Basé et améliorant ZOL ou une nouvelle implémentation ?
 
J'ai cru lire un "support complet de ZFS" donc jusque là les autres implémentation de ZFS n'ont pas toutes les fonctions ?