mon topic n'a pas vocation à chatouiller les opinions de chacun.
Je suis un petit utilisateur de linux et j'ai mis un peu les mains dans le cambouis pour me monter un serveur de fichier @home qui tourne sous ubuntu 9.10.
Tout est en RAID 1 et sous ext3. J'en suis plutot satisfait.
 
J'ai lu beaucoup de bien sur ZFS et son RAIDZ. Autant je pense comprendre l'intérêt de ZFS, autant je n'arrive pas à saisir la flexibilité de RAIDZ Tout le monde en parle en bien : quels sont ses avantages ?
 
à vous

Hello,
 
On parlera plutôt de la "flexibilité" de ZFS face à ext3, enfin tut un lot de fonctionnalités dernière génération comme les snapshots, la compression, le chiffrement, etc.
 
ZFS intègre en fait la notion de "volume management" directement dans le FS, ce qui est à l'usage certainement plus souple que d'avoir diférentes couches...
 
Le raidZ c'est "en gros" un RAID5 géré directement par ZFS (avec le probleme de write hole contourné, je sais pas comment, IIRC). De meme tu as le RAIDZ2 similaire au raid6.
 
Pour ton utilisation, je pense que ZFS/RAIDZ ne sont pas très interessants (déja faudra un miniumm de 3 disques pour raidZ, ensuite tu peux tres bien faire du raid5 et garder de l'ext3)
 
Je pense que le choix de ZFS/RAIDZ est une partie du choix de l'OS, choix qui se fait entre autre selon le support matériel, les besoins fonctionnels, ses connaissances propres en administration...
 
IMHO ZFS deviens surtout intéressant sur du gros gros filer, où sa souplesse devient intéressante. Sinon, ça consomme beaucoup trop en RAM pour pas grand chose, et il y a des risques de péter irrémediablement le FS si tu remplis trop tes durs, donc sur un petit filer, ça peut être compliqué.

merci pour tes reponses
 
en fait, j'ai 7 disques pour 3 piles RAID1 + 1 disque systeme (avec un montage pas forcément commun)
 
ce qui m'interesse dans le RAID1 c'est que je sais à quoi correspond tel disque physique (j'aime bien, quand je pars en vacances, mettre 1 disque de chaque grappe à la banque si jamais je me fais cambriolé)
 
ce qui m'intéresse dans le raidz ce sont ses performances et tous les avantages de ses metadatas et sa reputation "rock solid"
 
pour ce qui est de l'OS, je m'adapterai, ca ne me derange pas de mettre un peu les mains dedans et decouvrir (je ne suis pas encore assez mature sous linux pour etre ennuyé par une nouvelle syntaxe)
 
qu'est-ce qu'un gros filer ?
 
peux-tu m'en dire plus sur les risques liés au remplissage de données
 
d'avance

> ce qui m'intéresse dans le raidz ce sont ses performances et tous les
> avantages de ses metadatas et sa reputation "rock solid"
 
Qu'est ce que t'appelle "metadata" ?
 
vois le RAIDZ comme un RAID5, ça ira mieux pour ta comparaison avec le raid1
actuel. visiblement c'est blocant pour tes risques de cambriolage
 
Le côté fonctionnalité/perf de ZFS et du RAIDZ, mouai pourquoi pas, mais en as
tu besoins ?
 
Ne choisis pas ça par parce que ça t'as fait bander de lire un article dessus.
Si tu restais en ext3, tu mettrais du raid5 ? (dans ton cas c'est imho la
premiere question à se poser). Quelles fonctionnalités nextgen de ZFS te
servirais tu spécifiquement ?
 
> qu'est-ce qu'un gros filer ?
 
Je pensais à >= 10/12 disques, le "gros" en l'occurence c'est parce que je pense
parler à un particulier
 
> peux-tu m'en dire plus sur les risques liés au remplissage de données
> mdss[{}]
 
Cherche sur un moteur de recherche les mots clés "zfs fsck".
En gros il n'y a pas de fsck pour ZFS, ton FS est sencé ne jamais faillir.
 
Or, ça arrive, notamment quand tu as trop remplis ton disque, donc qu'il te
reste peu d'espace pour des opération de "maintenance/réparation à chaud"
automatique de ZFS (autorepair: en gros ZFS, par exemple en RAIDZ est capable de
détecter une anomalie sur un des membre du raid (bloc défecteu...) et utiliser
les infos d'un autre membre pour corriger le probleme. Copie de blocs, etc. Si
il n'y a plus de blocs dispo => fail, et pas d'outil fsck pour réparer)
 
Ceci dit j'ai jamais utilisé ZFS en production, j'espère donc que tu obtiendras
des avis de personnes plus expérimentées que moi

tes reponses sont deja tres pertinentes et je t'en remercie sincerement

Bonjour a tous, je voulais savoir si on pouvait utiliser zfs sur des dd et mdadm.
En effet, je souhaite monter un raid 5 de plusieurs dd et augmenter le nombre de disques durs ( maximum 9 ).
Or on ne peut pas augmenter le nombre de dd avec un raidz.
Comme le zfs combine plein d'aventage, je souhaite savoir si il est possible de l'utiliser avec mdadm.
Merci pour vos reponses,

Pas possible. Pour être efficace le RAIDZ doit attaquer les disques au plus bas niveau (disques entiers ou partitions).
 
Si tu rajoutes du mdadm par dessus, ton systeme de fichiers ZFS ne voit plus qu'un seul "disque virtuel" => tu perds toute la sécurité du RAIDZ.

ok, donc cela ne sert a rien.
Merci et, autre question : si j'ai par exemple, 5 DD de 2 to, et 4 de 80 go, avec zfs peut-on faire un raidz ( je sais qu'avec un raid 5 "classique " que c'est impossible mais la doc d'oracle sur opensolaris et le zfs est assez obscure je trouve) , et plus tard, remplacer les dd de 80 go par des dd de 2 to  ? Vu que zfs créé un volume avec tous les disques.
Sinon, avec un raidz1 de 6 DD et un raidz1 de 3 DD, peut on les faire apparaitre comme étant un meme volume ?

Alors
 
Question 1
=> Possible en ZFS comme en RAID 5, mais si tu mets tout sur un seul array (ou zpool), tu auras 4*80Go en stockage effectif (on ne prend en compte que la capacité des plus petits disques). Tu pourrais aussi créer 2 partitions sur tes disques de 2 To, une de 80 Go et une de 1.9 To pour mettre les partitions restantes dans un autre zpool.
 
Mais enfin le mieux ca reste de faire 2 zpools distincts pour tes 2 groupes de disques.
 
=> 2eme partie de la question
Tu peux ensuite changer les disques par des 2To et faire un resilver de ton pool, ce qui le fera grandir.
 
=> 3eme question.
Aucune idée.

ok, merci.

Un gros avantage de ZFS c'est qu'il fait un checksum de tous les fichiers. Un gros désavantage c'est qu'il faut utiliser solaris/opensolaris/openindiana.

Sinon pour ta question thrawn94, tu peux faire 2 vdev en RAIDZ, et une zpool des 2, donnant ce que tu recherches.

+1
 
cf : http://forum.setiaddicted.com/view [...] 38&start=0
 
Et avec des disques de 2 To en Advanced Format (secteurs 4k),

• En RaidZ (équivalent Raid 5),  le nombre de disque recommandé est : 3, 5, 9
• En RaidZ2 (équivalent Raid 6), le nombre de disque recommandé est : 4, 6, 10

Pour ajouter des disques, c'est possible par lot actuellement ; l'ajout d'1 disque après l'autre est en cours de développement : actuellement ça fonctionne chez certain et ça casse tout chez d'autres.
 
ZFS est très sécurisé & performant, cependant pour avoir de bonnes perf il revient plus onéreux que MDADM ou du Raid5 ou Raid6 Hard.
(1 Go de mémoire ECC / To géré, SSD en Raid1 pour SLOG + SSD pour le cache L2ARC, Carte contrôleur HBA LSI ...)
 
++

Pour la mémoire il faut une bonne quantité de base mais le 1Go/To c'est seulement pour les fonctions avancées de caching toussa (pour des serveurs de db ou autre usage du style). Idem pour le nombre de disques, ça ne change pas grand-chose en pratique. Par contre à partir du moment où l'intégrité des données est une des raisons d'être de ZFS, la mémoire ECC est effectivement recommandée, ce qui oblige à prendre du matos spécifique. La mémoire ECC coûte environ le double de la normale, ça reste assez peu cher en ce moment, par contre faut la carte mère et le CPU qui vont bien.
 
Pour l'ajout de disques actuellement ça veut dire ajouter un vdev à une zpool (faut donc ajouter au moins 3 disques d'un coup sinon pas de raidz possible). Les vdev sont en "RAID0" donc c'est à prendre en compte question risque, toujours avoir des backups.

Kingston ValueRAM DDR3 4 Go PC10600 ECC Reg actuellement à 50 € / il est même recommandé d'avoir de la ECC non Reg (44 € les 4 Go / 85 €les 2x 4 Go) mais dans ce cas on est "limité" à 24 Go ou 32 Go selon les cartes mères...
Certes il faut processeurs Xeon et des cartes mères "spéciales" du genre Supermicro X9SCM-F mais cette dernière dispose d'une puce graphique et également du contrôleur SAS LSI 1068E qui va bien (avec le firmware IT dont raffole ZFS ^^) ; au bout du compte on s'y retrouve !
1 zPool de 4 Vdev qui contiennent chacun 5 HDD (advanced format, 4k) en RaidZ... ça va, c'est déjà bien secure pour du Raid0 !

++

Pour la mémoire registered il faut des cartes mères spéciales qu'on reconnaitra à un nombre conséquent de ports RAM par socket (au moins 8), en général au moins dual socket, donc à réserver uniquement pour les gros serveurs qui ont besoin de 100Go ou plus de RAM.
 
En socket 1156, certains ont découvert (et Intel a confirmé) que les CPUs dual core (Pentium et i3) supportent l'ECC. Avec une mobo à moins de 200€ et un CPU à moins de 100€, on est donc paré pour ZFS.
 
Pour ma part vu que je vais avoir des DD en rab sans en avoir besoin avant quelques mois, je pense me monter une machine en ZFS avec du vieux matos qui traîne (sans ECC) et voir comment ça tourne, si j'arrive à configurer ça pour tourner sur mon réseau windows, etc., avant d'envisager de passer en production, avec du matos plus récent et de l'ECC.

Alors ça c'est une bonne nouvelle !!    
... reste qu'en non REG, on est limité à 24 Go ; sachant que pour faire bien il faut 1 Go / To géré, on peut donc avoir une zPool de 24 To max avec du i5 / i7 Sandy bridge
 
++

ça c'est uniquement pour utiliser le cache (ARC). Qui n'est utile que pour un usage entreprise style grosse database.
 
Et en sandy il faut du xeon pour l'ECC.

Chez AMD, tous les procos supportent la mémoire ECC il me semble bien, du Sempron 140 au FX en passant par le Phenom II X6.
(la mobo n'ayant pas d'importance)

salut je serait tenté d'utiliser zfs pour remplacer mdadm+lvm+ext4
je fais que du raid1
raid0 me tenterais mais ça oblige à créer deux partitions séparées  pour mdadm, donc on perd toute la souplesse quand au redimensionnement
 
à priori zfs permettrais cette souplesse ?

ça dépend ce que tu appelles redimensionnement. Déjà, tu parles de combien de disques ? Quand tu as un vdev de X disques, ZFS permet de remplacer tous ces disques (un par un) par des plus gros, et dans ce cas se redimensionnera. Pas possible par contre de rajouter un disque à un vdev. On peut en revanche agrandir une pool avec de nouveaux vdev.

ma config actuelle c'est 2 disque de 2 Teras avec partionnement identique
 
/dev/sdx1  de 8mo grubbios
/dev/sdx2  de 2Teras
 
grub installé dans le mbr des 2 diques, et il installe son core.img dans le partition de 8mo, ce qui permet alors à grub de booter sur mdadm et lvm
 
/dev/sdx2 contient donc mdadm /dev/md0
/dev/md0 est un volume physique lvm qui contient les volumes logiques
/dev/mapper/lvm-home
/dev/mapper/lvm-linux
/dev/mapper/lvm-linux2
/dev/mapper/lvm-swap
/dev/mapper/lvm-swap2
/dev/mapper/lvm-rescue
 
 
ce qui m'aurait interessé c'est d'avoir les os sur raid0
mais ça impose de créer une 3 ième partition gpt pour créer un mdadm /dev/md1 en raid0
 

En gros tu veux faire du matrix RAID. ZFS ne va pas t'aider, au contraire de ce point de vue c'est moins souple que mdam, il prend des disques entiers et ne s'emmerde pas avec des partitions.

ok
 
LVM aurait pu convenir car il permet le stripping et le mirroring, mais par contre le mirroring nécéssite un disque spécial pour le log
 
je pense que le log sert à assurer le côté transactionnel de l'écriture sur 2 disques, si par exemple l'écriture sur un disque échoue et que tout crash pour savoir quel disque "a raison"
 
c'est un point que je trouve pas clair dans mdadm d'ailleurs

Tu parles du bitmap ?
 
Il est facultatif, il sert uniquement à rendre plus rapide une resync éventuelle.
 
Quand tout crashe, mdadm se base sur un numéro de transaction inscrit dans les métadatas, le disque ayant l'index le plus élevé est celui qui a "raison".

ha ok
 
connais tu une doc qui explique comment il procède ?

Pour le bitmap, c'est assez simple.
 
De façon générale, mdadm ne se prend pas la tête, quand une anomalie est détectée sur l'un des disques, celui ci est marqué comme "dirty" et est resynchronisé entièrement.
 
Avec un write intent bitmap, les disques sont découpés en secteurs d'une certaine taille, qui sont signalés comme "dirty" dès qu'une opération d'écriture va commencer, et sont re déclarés comme sains quand cette opération s'est finie avec succès.
 
De cette façon tu ne resynchronises pas tous les disques mais juste une partie.
 
Le bitmap peut être interne (stocké dans les métadatas mdadm des disques) ou externe (dans une partition d'un disque séparé).
 
Mais il y a beaucoup de contre indications : il faut un FS en ext2/3/4, et en général il faut pas mal expérimenter pour ne pas trop perdre en perfs. Faut pas hésiter à utiliser une taille de chunks de 256 Mo ou plus.
 
Concernant le numéro de transaction, je ne connais pas les détails spécifiques. Il s'agit de l'event count que tu peux afficher en faisant un :
 
 mdadm --examine /dev/sdXX
 
sdxx étant un de tes disques ou partitions faisant partie de ton RAID et pas ton volume mdadm complet.
 
Exemple chez moi :
 
 Update Time : Tue Apr 10 12:00:17 2012
          State : clean
 Active Devices : 4
Working Devices : 4
 Failed Devices : 0
  Spare Devices : 0
       Checksum : 5d75f6b4 - correct
         Events : 878381

ok bon alors je vais garder ma solution mdadm raid1 + lvm éprouvée depuis 2 ans, avec un fail disk
 
je vais me faire une partition en raid0 tout de même, de 50g, pour au moins voir ce que donne un os là dessus
 
autre chose qui m'emmerde, windows 7 ne peut pas booter sur gpt, à moins d'avoir un bios uefi, ou alors d'utiliser gptsync qui permet d'émuler une partition mbr je crois

 
quelqu'un disait plus haut qu'on peut le mettre dans des partitions
c'est une erreur ?
 
sinon ce que je veux faire, serait possible en faisant
lvm+mdadm+lvm+ext4
 
je pourrais ainsi splitter le disque en une partie raid1 et l'autre raid0 grave à la couche lvm+mdadm, et les redimensionner
la couche lvm+ext4 permet alors de basculer des volumes logiques vers l'un ou lautre
 
dommage que zfs permette pas de le faire
je vois pas ce qui l'empêcherait en fait si ils voulaient ajouter une telle fonctionnalité

C'est une erreur, c'est pas fait pour fonctionner comme ça.
 
Quand à ce que tu veux, tu raisonnes à contre courant des pratiques actuelles. Ni ZFS, ni aucun FS moderne ne te permettra cela, que ce soit maintenant ou plus tard. Le stockage ne coute pas cher. Cumuler plusieurs niveaux de RAID sur les mêmes disques est une hérésie, qui défonce la possibilité de garantir des I/O correctes.
 
La tendance actuelle, c'est de rajouter des disques entier à ton volume manager, de créer différents pools avec des impératifs de sécurité / déduplication, et de laisser le volume manager s'occuper de la tambouille de placement des données sur les disques.
 
Vouloir absolument mettre en place ton idée avec un sandwitchage de LVM entre deux couches de mdadm, c'est loin d'être judicieux.

lol
 
déjà intel le permet avec son matrix raid, c'est donc qu'il y a une demande et un intérêt
c'est facile à faire avec mdadm, il suffit de faire des partitions dédiées pour chaque type de raid
lvm permet aussi de le faire, et mélanger stripping et mirroring
 
Le problème pour mdadm, c'est qu'avec des partitions on ne peut plus répartir facilement l'espace entre les deux zones raid.
LVM permet de le faire, mais le problème pour LVM est que le mirroring lvm nécéssite un troisième disque pour le log, ou de stocker le log en mirroir sur les deux disques, ce qui donne qqchose de moins performant que le mirroring mdadm
 
de plus ton discours est déconnecté de la réalité
la tendance actuelle je m'en tamponne
dans mon hcpc j'ai que 2 emplacements disques
 
et je vois pas en quoi ça défonce la possibilité de garantir des I/O correctes
t'as une partie du volume avec des IO raid 0 et l'autre partie avec des IO raid 1 et point barre
 
 
ZFS est envisagé comme un FS serveur, où de toutes façons on lésinera pas sur les disques
ça c'est sur, mais l'usage serveur concerne pas tous les usages pour lesquels on peut avoir besoin ou envie de faire un raid
 
utiliser deux couches lvm, le seul problème c'est le risque de se prendre les pieds dans le tapis
 
je vais me contenter de faire une partition de 50G et une de 1,9T, et faire un raid1 sur celle de 50G pour y mettre les os.

Tu raisonnes comme le mec qui utilise le dos d'un tournevis pour planter des clous. Je te parle comme une personne qui utilise quotidiennement des outils de management de disque sur un parc de serveurs (1500 serveurs pour être plus précis).
 
Les FS actuels sont bizarrement développés par des gens qui ont besoin de fonctionnalités pro. Ces gens la, tout comme moi, s'en foutent que sur ton HTPC tu n'aies que deux emplacements, et que tu veuilles tambouiller du RAID avec 2 bouts de ficelle.
 
Je te ferais également remarqué que je me suis légèrement emmerdé à te répondre d'une façon constructive. J'attends un minimum de respect lors d'une conversation.

mais j'en ai rien à carrer que t'en utilise quotidiennement à quantité industrielle
 
je te demande si oui ou non ça fait ce que je demande
donc tu réponds oui oui ou non et tu te passes de tes commentaires bidons
 
zfs fait raid1 et raid0
ça sert à quelque chose pour de l'industriel ?
non ça sert à que dalle, pourtant c'est dedans

Ca ne sert a rien de faire des remarques condescendantes.

http://mail.opensolaris.org/piperm [...] 02150.html
 

 
un type répond
 

 
il dit qu'ils en ont discuté mais ne l'ont pas encore implémenté
ça prouve bien que ma demande était parfaitement justifiée    

 
Et ca prouve bien que c'est la méthode dont j'ai parlée qui est la bonne. Ajouter un disque entier au pool, définir différents volumes avec des degrés de déduplication, laisser le volume manager s'occuper de la répartition des datas et de l'étalement des I/O.
 
Ce n'est pas ton idée de base qui est foireuse, je me répète, mais la façon dont tu voulais l'implémenter (sandwitcher différents systèmes dans un ordre contraire à l'ordre pour lequel ils ont été conçus pour être utilisés).
 
Si tu veux maintenir un système extensible et performant, il faut laisser la maitrise du volume entier au volume manager. Encapsuler différentes couches donne une impression de modularité, mais au final quand il y a ne serait ce qu'un bug sur l'une des couches, tu rends la récupération des données hasardeuse.

 
lol, c'est pas mon idée de base, c'est une idée de solution alternative faute de solution existante implémentée par zfs, qui ne permet pas cela malgré que ça m'aurait parut logique qu'il le fasse vu son fonctionnement.
 
Et c'est bien ce que le type dit dans la mailing list, que c'est prévu.
Et ce malgré ton affirmation que le stockage coute que dalle et qu'on prefera faire du raid10.
 
Cette même fonctionnalité est aussi prévue pour BTRFS.
 

 
Tu me fais marrer à vouloir faire la leçon comme si je savais pas moi même le risque que ça présentait et la maintenance bien plus compliquée
 

Excluons de nouveau le fait que je ne comprends pas le ton que tu emploies à mon égard.
 
Le fait que je trouves ton idée d'implémentation de ton besoin totalement bancale n'a jamais impliqué que je t'insulte personnellement, toutefois il semblerait que cela t'ait vexé.
 
LVM seul ne suffirait pas à obtenir ce que tu veux ? Tu peux faire du mirrorring et du stripping avec.
 
Edit : oublié des mots.
Edit2 : Viré une partie du post, l'historique me donne une idée de la personnalité du personnage

 
Donc, tu voulais faire du RAID1 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 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 ...