Bonjour à tous,
Depuis quelques jours, j'ai migré de freenas v7 vers nas4free. Lors de l'installation de 2 nouveaux disques, j'ai sélectionné le formatage ZFS miroir. J'ai été quelque peu dérouté car habitué à l'UFS, avec son formatage, puis la mise en place du raid, et enfin le point de montage.
Avec les infos que j'ai trouvé, pour le ZFS, j'ai créé un périphérique virtuel avec mes 2 disques en miroir (équivalent raid1 je suppose), puis un pool, et enfin des jeux de données (dataset).
J'ai trouvé l'ordre des choses à créer, mais, en ce qui concerne le pool et les dataset, c'est plutôt flou dans la compréhension de leur utilité.
Merci de me dire si j'ai bien compris ....pas mal de questions en même temps:
Le périphérique virtuel permet la gestion du système utilisé soit en raid, ou en disque unique.
Le pool serait un équivalent à un point de montage? (j'ai lu que tel quel les données pouvaient être placées dessus, même sans datasets?). Plusieurs pools permettraient de gérer les droits de chaque pool séparément et de manière différente?
Les datasets....? J'en ai créé, mais cela ne ressemble qu'à des dossiers à l'intérieur du pool. Quel est leur Intérêt?
Les volumes....? Je n'en ai pas créé, car je n'ai pas trouvé d'infos pertinentes dessus et n'ai pas compris leur utilité.
Une dernière question....
2 autres groupes de disques en UFS raid1 font partie de mon nas. Est il utile de tout transformer en ZFS? Si oui, c'est le pool existant que l'on peut augmenter en insérant ces nouveaux disques dans le pool? Seront ils toujours en miroir de type raid1?
Merci pour toute l'aide que vous pourrez m'apporter.
This is the old XigmaNAS forum in read only mode,
it will taken offline by the end of march 2021!
I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!
it will taken offline by the end of march 2021!
I like to aks Users and Admins to rewrite/take over important post from here into the new fresh main forum!
Its not possible for us to export from here and import it to the main forum!
Explication du format ZFS >>Newbee
Moderators: velivole18, ernie, mtiburs
-
brouce29
- NewUser

- Posts: 14
- Joined: 26 Sep 2014 00:31
- Location: Gouesnou - Finistère
- Status: Offline
Explication du format ZFS >>Newbee
9.2.0.1 x64-embedded on AMD Athlon(tm) II 170u Processor
ASUSTeK COMPUTER INC. M4A89GTO PRO 2 X 2GB DDR3
3X Raid1 >> 2X UFS (HD204UI + WD20EFRX), 1X ZFS (WD40EZRX)
ASUSTeK COMPUTER INC. M4A89GTO PRO 2 X 2GB DDR3
3X Raid1 >> 2X UFS (HD204UI + WD20EFRX), 1X ZFS (WD40EZRX)
- mtiburs
- Forum Moderator

- Posts: 951
- Joined: 09 Aug 2012 23:34
- Location: France - Besançon
- Status: Offline
Re: Explication du format ZFS >>Newbee
Bonjour et bienvenue !
Un dataset peut prendre les même caractéristiques que le pool ... ou pas !
C'est à dire qu'on peut avoir un pool tank normal, mais on peut avoir le dataset toto avec une compression de type lz4. Par contre dans le cas de titi, il aura obligatoirement les même propriété que tank.
Un exemple:
tank est un pool en mirroir de 2 disques de 2To
tank/vidéo sera un dataset avec des vidéos enregistré normalement
tank/fichiers sera un dataset avec une compression lz4
tank est le pool, video et fichiers seront des datasets avec des propriétés différentes
si ont crée tank/musique, musique aura les propriété de tank, car il héritera de celles de tank (mais on pourra changer cela)
Un dataset ne contient que des fichiers
Par exemple, on crée un volume de 100Go sur le pool tank nommé tank/truc
truc fera 100Go et bénéficiera des disques en mirroir, car on a un volume de 100Go crée sur un pool en mirroir.
Si vous placez ce volume en iscsi, d'une machine distante vous pourrez pointez dessus et de la machine distante, vous aurez un disque de 100Go et vous pourrez le formater en ext3 en FAT32, etc ...
Ensuite dans l'avenir, vous pouvez boostez votre pool ou juste une partie (un dataset précis par exemple) avec du cache gràce au SSD.
Voici une documentation concernant ZFS qui est ... la bible ZFS:
http://docs.oracle.com/cd/E19253-01/820 ... index.html
Un bémol: ZFS devrait être utilisé avec de la mémoire de type ECC, les mémoires normales ou non-ECC ne sont pas fiable et ZFS n'a pas de système d'auto-réparation, donc, on pourrait dire que cela est risqué. Cependant, par expérience vous vous rendrez compte que ZFS est beaucoup plus solide que les autres FS, et par conséquent même sans mémoire ECC, on utilise quand même ZFS.
Perso, cela fait des années que j'utilise ZFS, sur des machines "un peu légères", coupures de courants et sans onduleur, avec des câbles défaillants (mauvais contacts), rien, jamais eu un soucis !
Mais, il n'empêche qu'en cas de pb sur la mémoire, je peux perdre mon pool complet, c'est un choix ! moi je choisis ZFS les yeux fermés !
Oui, mais aussi en raidz1,2brouce29 wrote:Le périphérique virtuel permet la gestion du système utilisé soit en raid, ou en disque unique.
Oui, on peut avoir un pool sans dataset, un pool possède un point de montage attribué à la création qui peut d'ailleurs se changerbrouce29 wrote:Le pool serait un équivalent à un point de montage? (j'ai lu que tel quel les données pouvaient être placées dessus, même sans datasets?).
Oui mais beaucuop mieux que ça ! pas qu'aux droits, à la compression, aux quotas, au tailles de blocs utilisésbrouce29 wrote:Plusieurs pools permettraient de gérer les droits de chaque pool séparément et de manière différente?
Un dataset est un jeu de données équivalent à une "sorte de répertoire" mais en fait, c'est une sorte de sous-pool, par exemple, vous créez un pool "tank", et bien dedans vous pouvez créer le jeu de données tank/toto (notez bien qu'il n'y a pas le / avant tank), par contre quand vous voulez aller dans toto, il faudra faire cd /tank/toto. Dans tank, vous pouvez créer un répertoire titi (là, il s'agira d'un simple répertoire dans le pool tank). Vous pouvez créer aussi un répertoire tutu dans tank/toto (là, il s'agit d'un répertoire tutu qui se trouve dans le dataset toto qui est dans le pool tank)brouce29 wrote:Les datasets....? J'en ai créé, mais cela ne ressemble qu'à des dossiers à l'intérieur du pool. Quel est leur Intérêt?
Un dataset peut prendre les même caractéristiques que le pool ... ou pas !
C'est à dire qu'on peut avoir un pool tank normal, mais on peut avoir le dataset toto avec une compression de type lz4. Par contre dans le cas de titi, il aura obligatoirement les même propriété que tank.
Un exemple:
tank est un pool en mirroir de 2 disques de 2To
tank/vidéo sera un dataset avec des vidéos enregistré normalement
tank/fichiers sera un dataset avec une compression lz4
tank est le pool, video et fichiers seront des datasets avec des propriétés différentes
si ont crée tank/musique, musique aura les propriété de tank, car il héritera de celles de tank (mais on pourra changer cela)
Un dataset ne contient que des fichiers
un jeu de volume, c'est comme un périphérique, ça concerne des blocs purs et non pas une structure de type fichiersbrouce29 wrote:Les volumes....? Je n'en ai pas créé, car je n'ai pas trouvé d'infos pertinentes dessus et n'ai pas compris leur utilité.
Par exemple, on crée un volume de 100Go sur le pool tank nommé tank/truc
truc fera 100Go et bénéficiera des disques en mirroir, car on a un volume de 100Go crée sur un pool en mirroir.
Si vous placez ce volume en iscsi, d'une machine distante vous pourrez pointez dessus et de la machine distante, vous aurez un disque de 100Go et vous pourrez le formater en ext3 en FAT32, etc ...
Oui, Si votre architecture le permet (assez de mémoire RAM), c'est mieux en ZFS, car ZFS est extrêmement solide, résiste au coupure de courant en pleine écriture (il a été conçu pour subir cela grace au mode COW: Copy On Write soit: copie sur écriture).brouce29 wrote:Une dernière question....
2 autres groupes de disques en UFS raid1 font partie de mon nas. Est il utile de tout transformer en ZFS? Si oui, c'est le pool existant que l'on peut augmenter en insérant ces nouveaux disques dans le pool? Seront ils toujours en miroir de type raid1?
Ensuite dans l'avenir, vous pouvez boostez votre pool ou juste une partie (un dataset précis par exemple) avec du cache gràce au SSD.
Voici une documentation concernant ZFS qui est ... la bible ZFS:
http://docs.oracle.com/cd/E19253-01/820 ... index.html
Un bémol: ZFS devrait être utilisé avec de la mémoire de type ECC, les mémoires normales ou non-ECC ne sont pas fiable et ZFS n'a pas de système d'auto-réparation, donc, on pourrait dire que cela est risqué. Cependant, par expérience vous vous rendrez compte que ZFS est beaucoup plus solide que les autres FS, et par conséquent même sans mémoire ECC, on utilise quand même ZFS.
Perso, cela fait des années que j'utilise ZFS, sur des machines "un peu légères", coupures de courants et sans onduleur, avec des câbles défaillants (mauvais contacts), rien, jamais eu un soucis !
Mais, il n'empêche qu'en cas de pb sur la mémoire, je peux perdre mon pool complet, c'est un choix ! moi je choisis ZFS les yeux fermés !
Serveur Intel bi-Xéon P5530 / 8 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / ~30 x PI2b(ARM) sous Nas4Free / et ...(chhhut)... 1 seul Xigmanas
... et pas à jour en plus
(çà craint)
Conception d'un "système bizarre"
de "super-devices-autonomes" en NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h) en service depuis 2 ans.
Conception d'un "système bizarre"
- mtiburs
- Forum Moderator

- Posts: 951
- Joined: 09 Aug 2012 23:34
- Location: France - Besançon
- Status: Offline
Re: Explication du format ZFS >>Newbee
N'hésitez pas a revenir poser des questions !
Serveur Intel bi-Xéon P5530 / 8 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / ~30 x PI2b(ARM) sous Nas4Free / et ...(chhhut)... 1 seul Xigmanas
... et pas à jour en plus
(çà craint)
Conception d'un "système bizarre"
de "super-devices-autonomes" en NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h) en service depuis 2 ans.
Conception d'un "système bizarre"
-
brouce29
- NewUser

- Posts: 14
- Joined: 26 Sep 2014 00:31
- Location: Gouesnou - Finistère
- Status: Offline
Re: Explication du format ZFS >>Newbee
Bonjour et merci beaucoup.
Pas si simple effectivement de comprendre cette architecture... Mais rapidement je ressort ces phrases :
Si tel est le cas, quel est l'intérêt du miroir dans ce format?
J'ai 4Go de Ram sur la machine (non-ecc), est ce que cela parait suffisant?
Je vais aller voir votre lien chez oracle qui parait bien structuré, car il faut bien d travail personnel également...
Cordialement
Pas si simple effectivement de comprendre cette architecture... Mais rapidement je ressort ces phrases :
ZFS n'a pas de système d'auto-réparation
Je comprend que même en etant en ZFS miroir, en cas de défaillance d'1 disque, il n'est pas possible de récupérer ou reconstruire le ou les pools dessus?Mais, il n'empêche qu'en cas de pb sur la mémoire, je peux perdre mon pool complet, c'est un choix ! moi je choisis ZFS les yeux fermés !
Si tel est le cas, quel est l'intérêt du miroir dans ce format?
J'ai 4Go de Ram sur la machine (non-ecc), est ce que cela parait suffisant?
Je vais aller voir votre lien chez oracle qui parait bien structuré, car il faut bien d travail personnel également...
Cordialement
9.2.0.1 x64-embedded on AMD Athlon(tm) II 170u Processor
ASUSTeK COMPUTER INC. M4A89GTO PRO 2 X 2GB DDR3
3X Raid1 >> 2X UFS (HD204UI + WD20EFRX), 1X ZFS (WD40EZRX)
ASUSTeK COMPUTER INC. M4A89GTO PRO 2 X 2GB DDR3
3X Raid1 >> 2X UFS (HD204UI + WD20EFRX), 1X ZFS (WD40EZRX)
- mtiburs
- Forum Moderator

- Posts: 951
- Joined: 09 Aug 2012 23:34
- Location: France - Besançon
- Status: Offline
Re: Explication du format ZFS >>Newbee
Le mirroir concerne la duplication des données.
Le pb de la mémoire en ECC est extrêmement limité mais peut exister, il s'agit de rayons cosmiques (ça peut faire rire) qui vont faire changer l'état d'un bit sur la mémoire, si la mémoire n'est pas ECC, le système ne va pas le voir. Ensuite il faut que cela se produise sur la portion la plus risquée (l'index qui contient l'arbre des données) et que cela se produise à un moment précis, car ZFS fait beaucoup de checksum dans ses transactions.
En gros il faut qu'au moment ou il écrit dans son "sommaire" la valeur d'une page correspondante soit modifiée et qui prenne ça pour du pain béni. En fait qu'il fasse référence a un bloc autre que celui qu'il faut.
Que le disque soit simple, en une dizaine de mirroir ou en raidz2, ça ne change rien car celà ne concerne pas les données mais son "index".
Le pb est que si cela se produit, il est impossible de réparer, car ce n'est pas une erreur "exploitable" (car ce n'est pas vraiment une erreur en soit, juste un "ce bloc est là-bas ... alors qu'en fait il est juste par ici")
Il faut savoir qu'un serveur (engin d'importance") ne peut pas être non-ECC (ECC bloque la machine sur une erreur et ECC-registry corrige l'erreur et ne bloque pas le fonctionnement du système).
C'est un risque.
Pour ma part, j'ai deux nas qui font de la déduplication de MV et je copie séparément mes MV sur l'un et sur l'autre, ils ne sont pas ECC donc je double les machines mais totalement: je n'ai pas de lien entre, le lien est la "source". Une sorte de "mirroir manuel" mais que sur les données.
Il faut en être conscient.
Le pb de la mémoire en ECC est extrêmement limité mais peut exister, il s'agit de rayons cosmiques (ça peut faire rire) qui vont faire changer l'état d'un bit sur la mémoire, si la mémoire n'est pas ECC, le système ne va pas le voir. Ensuite il faut que cela se produise sur la portion la plus risquée (l'index qui contient l'arbre des données) et que cela se produise à un moment précis, car ZFS fait beaucoup de checksum dans ses transactions.
En gros il faut qu'au moment ou il écrit dans son "sommaire" la valeur d'une page correspondante soit modifiée et qui prenne ça pour du pain béni. En fait qu'il fasse référence a un bloc autre que celui qu'il faut.
Que le disque soit simple, en une dizaine de mirroir ou en raidz2, ça ne change rien car celà ne concerne pas les données mais son "index".
Le pb est que si cela se produit, il est impossible de réparer, car ce n'est pas une erreur "exploitable" (car ce n'est pas vraiment une erreur en soit, juste un "ce bloc est là-bas ... alors qu'en fait il est juste par ici")
Il faut savoir qu'un serveur (engin d'importance") ne peut pas être non-ECC (ECC bloque la machine sur une erreur et ECC-registry corrige l'erreur et ne bloque pas le fonctionnement du système).
C'est un risque.
Pour ma part, j'ai deux nas qui font de la déduplication de MV et je copie séparément mes MV sur l'un et sur l'autre, ils ne sont pas ECC donc je double les machines mais totalement: je n'ai pas de lien entre, le lien est la "source". Une sorte de "mirroir manuel" mais que sur les données.
Il faut en être conscient.
Serveur Intel bi-Xéon P5530 / 8 X Ubuntu Serveur 18.04 LTS - ZFS-BTRFS-bcache / ~30 x PI2b(ARM) sous Nas4Free / et ...(chhhut)... 1 seul Xigmanas
... et pas à jour en plus
(çà craint)
Conception d'un "système bizarre"
de "super-devices-autonomes" en NFS gérés par des micro-serveurs SAN(+nas) sous N4F (11 super-devs en raidz3) taille actuelle: 16To / prévue: 64To / théorique: 320To (consommation < 15W en veille - 24/24h) en service depuis 2 ans.
Conception d'un "système bizarre"