ZFS sous GNU/linux

ZFS est un système de fichiers dédié serveur qui promet de réconcilier les administrateurs système avec les systèmes de fichiers. Il a été écrit par les développeurs de Sun. Il est donc disponible nativement sous Solaris. Il simplifie toutes les opérations qui nous horripilent ou nous rebutent. Il a une fonctionnalité qui m'a vraiment fait craquer et qui me paraît tellement évidente qu'on se demande pourquoi les autres systèmes de fichiers ne la proposent pas : il est capable (avec un système de disques redondants) de s'auto-réparer ! Le code [0] est placé sous licence CDDL, approuvée par l'OSI (l'Open Source Initiative [1]), c'est donc un logiciel libre même si l'on peut regretter ce choix pour des raisons éthiques [2]. Voyons ce dont ZFS est capable.

1. Des chiffres

Lorsque l'on parle de chiffres, pour un système de fichiers, il s'agit généralement de ses limites. ZFS, dans ce domaine, a été conçu directement pour le futur, jugez plutôt :

- Système de fichiers entièrement 128 bits, c'est-à-dire non seulement pour le nombre d'inodes, mais aussi pour la taille maximale d'un fichier .

- 264 soit plus de 18 milliards de milliards de fichiers au maximum dans chaque système de fichiers.

- 248snapshots au maximum. Si on en fait 10 par seconde, on peut tenir pendant plus de 890 000 ans ! Mais, il faudrait de la place et justement…

- 16 exa octets, soit plus de 16 000 peta octets. C'est la taille maximale d'un système de fichiers. 16 exa octets, c'est aussi la taille maximale d'un fichier !

- 248 fichiers au maximum dans un répertoire.

- 256 zeta octets, soit plus de 256 000 exa octets. C'est la taille maximale d'un pool (un ensemble de périphériques) qui peut contenir au maximum 264 systèmes de fichiers.

- Les pools peuvent être formés d'au maximum 264 périphériques.

Ces chiffres sont tellement immenses qu'on ne se rend pas bien compte de ce que cela représente. Aussi, il est probable que l'énergie nécessaire pour remplir un système de fichiers comme celui-là soit si gigantesque qu'elle pourrait suffire à faire bouillir l'eau des océans [3]. On comprend mieux pourquoi ce système de fichiers a été nommé Zeta File System, soit ZFS.

2. Installation

Donc, en cherchant bien, on trouve Ricardo Correia (connu sous le pseudonyme wizeman), un gentil développeur, qui a porté ZFS pour qu'il utilise fuse sous GNU/Linux. En effet, la licence CDDL est incompatible avec la licence GPL (dans sa version 2), celle du noyau GNU/Linux. C'est pourquoi ZFS n'est pas intégré au noyau et que l'on doit utiliser fuse pour le faire fonctionner sous GNU/Linux. Ce n'est par exemple pas le cas de FreeBSD où ZFS est intégré nativement depuis la version 7.0. Sur le site de FreeBSD [4], il est écrit qu'il s'agit d'un support expérimental, mais un certain D.B., rédacteur en chef d'un magazine sur GNU/Linux me souffle qu'en réalité c'est « intégré de manière très très propre » !

Du coup, avant toute chose sous GNU/Linux (les noms des paquets cités ici proviennent de ma Debian), il faut installer fuse-utils et aussi libfuse-dev, car nous allons compiler le programme qui utilise les structures de fuse. Il faut aussi installer libaio-dev et libaio1 qui permettent d'effectuer les entrées/sorties de manière asynchrone. La bibliothèque de compression de données zlib vous sera demandée avec sa version de développement. Il faut également un noyau GNU/Linux2.6.x supérieur à 2.6.15 et une glibc avec les pthreads dans une version supérieure à 2.3.3. Le système de compilation utilise la commande scons [5] en remplacement de la commande make. Il vous la faudra également.

Téléchargez [6] l'archive et décompressez-la avant de lancer la compilation :

Si, comme moi, vous avez une machine dont l'âge est honorable, il faudra une bonne dizaine de minutes avant que cette opération ne se termine.

Installons le programme :

Et voilà !!

Par défaut, tout s'installe dans /usr/local/sbin. Vous pouvez modifier cela en spécifiant une option à scons :

3. Tour d'horizon rapide des commandes et des fonctionnalités

Nous venons d'installer les commandes zdb, zfs, zfs-fuse, zpool et ztest.

zdb est la commande qui permet de diagnostiquer des pannes et erreurs de ZFS. Toutefois, comme le fonctionnement de ZFS lui garantit d'être toujours cohérent et qu'il se répare tout seul, cette commande n'est pas très utile dans un premier temps.

zpool permet de gérer les « pools » de stockage, c'est-à-dire les regroupements de disques de stockage.

zfs permet de configurer le ou les systèmes de fichiers contenus dans les « pools ».

ztest permet de faire des tests.

zfs-fuse va nous servir sous GNU/Linux puisqu'il s'agit du mauvais génie (le démon quoi !) qui gère tout ça !!

Mentionnons l'option pour obtenir l'aide des commandes. Cette dernière n'étant pas très POSIX [7], elle est un peu inhabituelle. Aussi, vous devrez utiliser l'option -?.

Les fonctionnalités présentes dans la version 0.5 sont les suivantes :

- Créer et détruire des pools, des snapshots et des clones.

- Fonctionnalités de raid, raid-0 ou agrégats, raid 1 ou miroir, raid 5 ou à parité contrôlée (cette fonctionnalité se nomme raidz pour ZFS), raid 6 à double parité (nommée raidz2).

- Possibilité d'utiliser n'importe quel périphérique en mode bloc ou n'importe quel fichier (sauf un issu d'un système de fichiers ZFS) pour réaliser un périphérique virtuel.

- La compression, la détection d'erreur, la vérification des données ainsi que l'auto-réparation (sur un volume de type raid redondant type raid 1, raid 5 ou raid 6).

- Les quotas et la réservation fonctionnent, même s'il ne s'agit pas de « vrais quotas » à la sauce POSIX du terme.

- Sauvegarde et restauration (via les snapshots).

Bien qu'il y ait déjà de nombreuses fonctionnalités opérationnelles, il en existe beaucoup d'autres qui ne le sont pas encore, soit qu'elles ne sont pas encore implémentées, soit qu'elles ne peuvent l'être du fait de limitations dues principalement à fuse (que l'on remercie quand même d'exister). Pour avoir une idée plus précise des fonctionnalités qui restent à écrire, reportez-vous au fichier STATUS qui se trouve à la racine des sources.

4. Passons aux choses sérieuses

4.1 Création d'un pool

Avant toute chose, vérifiez que fuse est bien là et lancer le processus ZFS pour ce dernier comme suit. Attention, la commande ne se termine pas, ouvrez donc un terminal dédié :

Si cela ne fonctionne pas, reportez vous au paragraphe 6. Pour faire mes tests, vu qu'à la maison je n'ai pas un serveur de fichiers avec plusieurs contrôleurs et plusieurs disques, j'utilise des fichiers comme s'ils étaient des disques. Je me crée dix « disques » de 512 Mo :

Après un long moment (ma machine a mis plus de 5 minutes), vous obtenez dix magnifiques fichiers, tous d'une taille identique de 512 Mo. Nous admettrons qu'il s'agit là de dix disques durs très haute performance !

Donc, nous allons créer un pool avec les dix disques, en raidz2, c'est-à-dire un genre de raid 6 et disons que, comme on est très prudent, on va utiliser un disque de réserve (« spare » en anglais). On souhaite aussi que le volume correspondant soit monté sur /media/zfs_test (qui est un dossier qui n'existe pas sur le système utilisé). Utilisons la commande suivante :

Hop et voilà !! Si si, c'est tout ce qu'il y a à faire. D'ailleurs, vérifions tout de suite avec la commande df -h qui donne :

3,4 Go de libre, c'est bien 7*512Mo, car, pour schématiser, on a 9 disques dans le raidz2 dont 2 disques de parités soit 7 disques utiles plus un disque de réserve (ici spare). Cette place est directement utilisable, car montée automatiquement sur /media/zfs_test (comme on lui avait demandé). Ici, pas besoin d'un long mkfs. La commande s'est exécutée en un clin d’œil : la taper a presque été plus long ! Une commande utile à ce stade est zpool status qui permet de connaître l'état des pools (ici un seul) :

Ici, on voit très nettement qu'il y a 9 disques dans le raidz2 que j'ai nommé « raid6 » et un disque de réserve qui est disponible (AVAIL). Cette commande nous servira, par la suite, pour connaître l'état du pool.

Copions donc des données. Une commande du -hs /var/cache m'indique que ce dernier occupe 3,4 Go, parfait pour être copié dans mon volume de test :

Là, pour le coup, c'est long, très long même, plus de 30 minutes sur ma machine. Mais c'est normal, car toutes les opérations ont lieu sur le même disque physique. De plus, ZFS crée le système de fichiers à la volée et calcule les sommes de contrôle (checksums) qui lui seront utiles au cas où il lui arriverait malheur (et croyez-moi, je ne vais pas être tendre). Si, comme moi, vous essayez de mettre plus de données que le volume ne peut en contenir, vous allez vous rendre compte, vers la fin, que ZFS cherche de la place et se réorganise. Si vous regardez la place libre avec la commande df -h régulièrement, il est possible que vous voyiez cette dernière augmenter, alors même que vous copiez des données !! Astuce : Pour réaliser cela, utilisez la commande watch comme suit (utilisez [Ctrl-C] pour quitter le programme) :

La recherche de place libre est très consommatrice de ressources et écroule totalement les performances (sous GNU/Linux en tout cas). Il est préférable de ne jamais remplir totalement un système de fichiers ZFS pour éviter ce problème. Notamment, cela vous évitera de vous demander pourquoi vous n'arrivez pas à effacer un fichier de 2 Go quand votre pool ZFS est plein à 99%...

Notons que ZFS gère plusieurs types de systèmes de fichiers tels que « raidz2 » que nous venons de voir ou « raidz » qui est une sorte de raid5 et « mirror » qui est une sorte de raid1. De base, il gère le raid0 qui est un simple agrégat. Nous le verrons plus tard. Il est possible de mélanger, dans une certaine mesure, tout cela.

4.2 Faisons souffrir le système de fichiers

4.2.1 Un disque rempli d'erreurs

Écrivons n'importe quoi dans le fichier disque_4 par exemple :

Après une manœuvre pareille, le contenu du fichier disque_4 n'est plus du tout le même qu'avant.

La commande zpool status annonce qu'il y a eue une erreur, mais que les applications n'ont pas été affectées. Elle indique aussi les actions à réaliser pour effacer les erreurs ou pour remplacer le disque défectueux. Par contre, l'accès aux fichiers dans /media/zfs_test/ reste possible et sans erreurs, car ZFS les détecte et les corrige à la volée. À noter que la commande zpool scrub raid6 permet de corriger l'ensemble des données du volume (moins le volume est rempli, plus c'est rapide).

La colonne CKSUM de la commande zpool status indique le nombre de sommes de contrôle trouvées en erreur.

4.2.2 Un disque en moins

Bon, dans la vrai vie, c'est rare que l'on puisse réécrire sur les secteurs défectueux d'un disque. Pour simuler un disque défectueux, tuez le processus zfs-fuse, supprimez le fichier de votre choix, relancez le processus zfs-fuse et réimportez le pool (voir § 6.) :

L'indication est claire : il manque un disque. La commande conseille de le brancher et de le mettre en ligne en utilisant la commande zpool online.

4.2.3 Deux disques en moins ! Vite, utilisons le disque de réserve !

Soyons fous, recommençons et supprimons disque_5. Les sorties sont les mêmes, mais, cette fois, nous n'avons plus la ceinture, ni les bretelles et le moindre problème dans l'un des disques restant serait fatal aux données. Utilisons donc le disque de spare :

Et voilà ! Comment ça et voilà ? Si si, je vous assure, c'est tout, ZFS s'occupe de reconstruire en arrière-plan le système de fichiers, de noter que le périphérique disque_9 est maintenant utilisé et qu'il remplace disque_4 et vous continuez d'avoir accès à vos fichiers de manière transparente, comme si de rien était :

Regardez bien. La commande indique même depuis combien de temps elle reconstruit (ici 2 minutes) et combien de temps il va lui falloir pour terminer (à vitesse constante, ici 16 minutes – en réalité, il ne lui a fallu que 12 minutes).

4.2.4 Allons y gaiement...

Ce qui est agréable avec la commande zpool status, c'est qu'elle indique tout de manière précise et concise. Par exemple, supprimons le disque de spare (disque_9) et inscrivons 10 Mo de données aléatoires dans l'un des disques restants. Le résultat sera qu'un certain nombre de fichiers seront illisibles, oui, mais lesquels ?

Après l'import du nouveau pool très dégradé, zpool status nous indique bien avoir perdu le disque de réserve et qu'il n'y a pas assez de disques pour la réserve. Mais, la commande n'indique pas les éventuelles erreurs dans le système de fichiers (erreurs dues à la commande dd). La commande zpool scrub raid6 permet de parcourir l'ensemble des données pour y détecter des erreurs et éventuellement les corriger, le tout de manière transparente. Voyons le résultat avec la commande zpool status –v :

Et ainsi de suite... La commande indique non seulement le disque où se sont produites les erreurs, via la colonne CKSUM, mais aussi très précisément quels sont les fichiers qui ne sont plus bons. Dans l'exemple, il s'agit de 79 fichiers du dossier /apt/archives/.

Dans le cas d'un système de fichiers réel, si une telle chose se produit, l'administrateur connaît rapidement le nom des fichiers erronés et peut, après avoir réparé, c'est-à-dire remplacé les disques, faire une restauration à partir de la sauvegarde.

4.2.6 Remplacement des disques

Comme vous avez des données très importantes sur vos disques, vous commandez de nouveaux disques qui iront remplacer les anciens. Manque de bol, la capacité ridicule de 512 Mo n'existe plus et les seuls nouveaux disques que vous trouvez sont des disques de 650 Mo :

Comment va se comporter le système avec des disques de taille supérieure ? Est-ce qu'il va subsister de la place non utilisée sur le disque ?

Le remplacement des disques manquant est possible, même avec des disques de plus grande taille. Toutefois, il n'est pas complètement effectif dans notre exemple, notamment, le système refuse obstinément d'enlever l'ancien disque arguant du fait qu'il manque des données. Supprimons donc ces données qui sont de toute manière perdues (on pensera à remercier l'administrateur d'avoir fait des sauvegardes sur bande) :

Demandons-lui de se réparer avec une commande du type fsck :

La commande s'exécute en arrière plan et zpool status raid6 vous dit où elle en est. En attendant qu'elle termine, profitez-en pour regarder le résultat de la commande zpool iostat -v raid6. Elle indique la place utilisée et restante des pools et systèmes de fichiers, ainsi que le nombre d'opérations d'écriture et de lecture par secondes effectuées sur chaque disque et la bande passante que cela représente. Il est possible de demander à ce que l'exécution de cette commande se répète selon un intervalle donné, par exemple toutes les 3 secondes : zpool iostat -v raid6 3.

Lorsque la commande est terminée, vous pouvez enlever les anciens disques défectueux avec la commande zpool detach raid6 /tmp/zfs_test/disque_5 ou en utilisant le nom système du disque (dans notre exemple, il s'agit de : 2705405041636850921).

La commande zpool list qui donne un résumé très synthétique des pools indique qu'il n'y a pas eu d'augmentation de la capacité. Si l'on souhaite que la capacité augmente, il faudra remplacer tous les anciens disques avec des nouveaux de capacité identique. Tout cela se réalise bien entendu alors que le système de fichiers est monté, vous pouvez accéder à vos fichiers en toute transparence !

Un bémol toutefois, pour que mon système prenne effectivement en compte l'augmentation de la capacité totale, il a fallu que j'arrête puis relance zfs-fuse et que j'importe à nouveau le pool. Cette manipulation n'a pris que quelques secondes, mais, pendant ces quelques secondes, les fichiers ne sont plus accessibles (pensez à prévenir les utilisateurs).

4.2.7 Augmentation de capacité par ajout d'un nouveau raidz au pool

Un autre moyen d'augmenter la capacité est d'ajouter un nouvel ensemble de disques dans notre pool (que nous avons nommé raid6). Nous pouvons faire cela avec la commande suivante :

Il faut garder en tête que ZFS a besoin d'un nombre de périphériques identiques entre ensemble de fichiers d'un même pool. Cela lui simplifie le travail (il est toutefois possible de le forcer avec l'option -f). Nous obtenons ainsi une sorte de raid 0+6 :

Soit une capacité portée à

ou encore :

En faisant ainsi, on a augmenté, de manière transparente, la taille totale du système de fichiers.

La taille donnée par la commande zfs-list et celle donnée par la commande du -h sont différentes. Il semble que la commande zfs-list ne prenne pas en compte dans son calcul les disques réservés au calcul des sommes de contrôle (deux dans notre cas).

4.2.8 Rappel des commandes utiles

zpool create nom_du_pool type_du_pool noms_des_périphériques crée un pool selon les options spécifiées. Le type du pool peut-être « mirror », « raidz » ou « raidz2 ».

zpool destroy nom_du_pool pour détruire un pool entier. Attention, cette commande ne demande pas de confirmation et il ne semble pas exister d'option « garde fou » du type « -i » des coreutils !

zpool iostat -v permet l'affichage des statistiques d'entrées/sorties des pools tout en indiquant la répartition des données et de ces entrées/sorties sur chacun des fichiers ou périphériques constituant le pool.

zpool status -v donne l'état de chacun des pools. Cette commande détaille les erreurs lorsqu'il y en a.

5. Systèmes de fichiers

La commande zpool que nous venons de voir crée un système de fichiers racine dans le pool et le monte sur le point de montage qu'on lui a indiqué. Il est toutefois possible de créer, dans le pool, des systèmes de fichiers indépendants. Listons les systèmes de fichiers déjà utilisables :

Nous retrouvons notre système de fichiers raid6 (qui est aussi le nom du pool) monté sur /media/zfs_test. Nous pouvons maintenant créer au maximum 264 systèmes de fichiers dans ce pool, par exemple :

Ce qui donne :

Vous pouvez vérifier avec la commande df -h que les systèmes de fichiers sont bien montés. Ils se partagent tous un même espace de stockage qui est le pool en lui-même. Si on le souhaite, on peut remplir raid6/home et, dans ce cas, il ne restera plus de place pour les autres systèmes de fichiers. On peut voir cela comme des répertoires. À la différence prêt qu'il est possible de préciser quelques options nommées « propriétés ». Par exemple, il est possible de redéfinir le point de montage :

La dernière commande permet de remonter le système de fichiers dont on vient de modifier le point de montage, le changement l'ayant démonté automatiquement. Si on change plusieurs points de montage, on pourra utiliser la commande zfs mount -a.

Pour obtenir les propriétés d'un système de fichiers, utilisez la commande zfs get all nom_du_systeme_de_fichiers, par exemple :

Le paramètre SOURCE peut prendre trois valeurs :

- default qui indique une valeur par défaut (ou inchangée) ;

- local qui indique que la valeur a été fixée spécifiquement pour ce système de fichiers ;

- inherited qui indique que la valeur est héritée d'un système de fichiers parent.

On a déjà vu que l'on peut changer le point de montage en changeant la propriété mountpoint, mais ce changement nécessite de remonter les systèmes de fichiers. Heureusement, ce n'est pas toujours le cas et, notamment, il est possible de changer, de manière transparente et alors que le système de fichiers est en fonctionnement, certaines propriétés telles que compression, quota et reservation par exemple.

5.1 Compression

Il est possible d'indiquer, à la volée, à un système de fichier ZFS s'il doit compresser les données ou non. Pour l'exemple, créons un système de fichiers nomméraid6/etc. En général, ce dossier contient plein de fichiers de configuration de type texte qui se prêtent bien à la compression. Puis, indiquons-lui qu'il doit maintenant compresser les données en mettant la propriété compression à on. Enfin, copions le contenu de /etc et voyons le résultat de la compression :

La propriété compressratio indique le taux effectif de compression des données, ici un peu plus de 2 fois.

Lorsqu'il existe des données préalablement à la modification de la propriété, ces dernières ne sont pas compressées. Elles restent non compressées sur le disque. Toutefois, et c'est là que c'est intéressant, les nouvelles données ajoutées aux fichiers non compressés, seront, elles, compressées. Ainsi, un fichier peut avoir une partie non compressée et une partie compressée (celle qui aura été écrite après le changement de la propriété).

De même, lorsque l'on modifie à nouveau la propriété vers la valeur off, c'est-à-dire sans compression, les données ajoutées le seront sans compression, mais l'état de celles qui étaient compressées précédemment n'est pas modifié.

Cet exemple montre que certaines propriétés affectent les blocs et pas, comme on pourrait s'y attendre, les fichiers eux-mêmes.

5.2 Quotas

Les quotas sur ZFS ne fonctionnent pas à la manière des quotas POSIX. Ils sont fixés par système de fichiers et non par utilisateur. Deux propriétés permettent de les fixer :

- quota limite l'espace du système de fichiers, pour lui-même et tous les systèmes de fichiers fils, incluant les instantanés ou snapshots.

- refquota fait exactement la même chose, mais la limite n'inclut pas les instantanés ou les descendants.

Il est donc possible de jouer avec ces deux propriétés de manière à limiter la taille maximale occupée par un système de fichiers. Dans notre exemple, on pourrait fixer la taille maximale de /var à 5 Go avec la propriété refquota et autoriser 5 Go pour les instantanés en fixant à 10 Go la propriété quota.

Dès que l'une ou l'autre des propriétés sont définies, la commande df -h indique la taille du disque, ainsi que la place restante. Elles sont déterminées par la propriété qui contraint le plus (en général, il s'agit de refquota).

Utilisée avec l'option de compression, le quota s'applique, une fois les données compressées. Ainsi, si un système de fichiers est plein avec un quota de 100 Mo, que la propriété de compression est à vrai et que le taux de compression est de 2x alors ce système de fichiers contient 200 Mo de données non compressées.

Lorsque que le quota est atteint, une erreur survient pour l'indiquer et, dès lors, il n'est plus possible d'ajouter des données ou des fichiers.

5.3 Réservation

La propriété reservation permet de réserver de l'espace sur un système de fichiers. Cet espace est directement et immédiatement consommé sur l'espace disponible du système de fichiers parent. Il doit donc être disponible au moment où l'on fixe la valeur de la propriété.

5.4 Héritage des propriétés

Certaines propriétés peuvent être héritées directement de leur(s) parent(s). C'est le cas par exemple pour la compression, le point de montage, les quotas et la réservation. Si l'on change les propriétés d'un système de fichiers, tous ses sous-systèmes hériteront de la nouvelle valeur.

5.5 Instantanés ou snapshots

Comme pour toutes les fonctionnalités que nous avons déjà vues, celle ci est très simple d'emploi. De plus, la création d'un instantané ne consomme pas de place supplémentaire. Seules les données créées ou modifiées à la suite de cette création utiliseront de l'espace supplémentaire. Un exemple d'utilisation des instantanés :

Maintenant que nous avons vu ce qu'il y a dans notre répertoire, créons notre premier instantané en utilisant la commande zfs snapshot nom_du_snapshot et observons le résultat :

Comme on peut le voir, l'instantané premier n'occupe aucune place. Copions des données :

Il est ainsi possible de créer autant d'instantanés que l'on désire. Nous pouvons par exemple réitérer l'opération : créer un instantané, puis copier un fichier dans le répertoire :

L'intérêt de tout cela, c'est qu'il est possible de revenir en arrière. Par exemple, je peux revenir à l'état initial en utilisant la commande zfs rollback raid6/home@premier ou encore à l'état juste avant la copie de mon dernier fichier avec zfs rollback raid6/home@deuxieme. Mieux, il est même possible d'obtenir la différence avec la commande zfs send -i raid6/home@premier raid6/home@deuxieme > diff. Dans l'exemple, il s'agit du fichier /etc/passwd copié entre les prises des instantanés. Cette différence pourra être relue avec la commande zfs receive qui créera alors un instantané correspondant à ce qui lui a été envoyé.

Ces deux dernières commandes peuvent être utilement combinées avec ssh pour, par exemple, générer des sauvegardes différentielles et les envoyer sur un serveur distant.

6. Après un redémarrage

Dans le cas où vous avez redémarré votre machine, votre beau système de fichiers ZFS n'est plus présent. Que faire pour le retrouver ? Comment se souvenir, après quelques jours, mois (ou années) quelle configuration vous aviez utilisée, les disques de spare, raidz1, raidz2, mirror ou pas, le point de montage ?

Avec ZFS, rien de plus simple. Après avoir chargé le module fuse et redémarré le démon zfs-fuse, rendez-vous directement dans le dossier où vous avez créé vos fichiers (les faux disques) et tapez la commande zpool import -d ..

Cette commande recherche, parmi les fichiers du dossier courant (« . »), les périphériques virtuels (vdev), puis elle indique le nom et la configuration de chaque pool trouvé parmi ces périphériques. Pour importer réellement un pool, nommez-le à la fin de la commande, par exemple : zpool import -d . raid6 . Après quelques instants, le système de fichiers est à nouveau monté (sur le bon point de montage) et prêt à être utilisé.

Si le système de fichiers n'est pas monté correctement, vérifiez que vous avez bien le module fuse chargé (modprobe fuse), que vous avez bien lancé le démon zfs-fuse (zfs-fuse –no-daemon) et que les répertoires sur lesquels sont montés vos systèmes de fichiers ZFS sont vides.

7. En conclusion

Cet article n'a pas fait le tour de toutes les fonctionnalités et propriétés de ZFS. Aussi, le lecteur curieux pourra regarder de près le système de clones et les permissions liées à l'administration par exemple.

Il est vraiment dommage que ce système de fichiers ne puisse être inclus nativement dans le noyau GNU/Linux par la faute d'une bête incompatibilité de licence...

Bien entendu, tout ce qui est décrit dans cet article est réalisable nativement, c'est-à-dire sans fuse et son démon zfs-fuse, sous FreeBSD 7.0, Solaris 10, Mac OS X et, me souffle-t-on, Nexenta [11].

Je tiens à remercier mes mentors qui ont été attentifs aux erreurs et imprécisions et m'ont patiemment relu et corrigé : Bruno Bonfils, Guillaume Lelarge et Sébastien Tricaud.

Références

[0] http://opensolaris.org/os/community/zfs/source/

[1] http://opensource.org/

[2] http://www.opensolaris.org/os/licensing/cddllicense.txt

[3] http://blogs.sun.com/bonwick/date/20040925#128_bit_storage_are_you

[4] http://www.freebsd.org/releases/7.0R/announce.html

[5] http://www.scons.org/

[6] https://developer.berlios.de/project/showfiles.php?group_id=6836

[7] http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap12.html#tag_12_02

[8] http://www.manpagez.com/man/8/zpool/

[9] http://docs.sun.com/app/docs/doc/817-2271/gazss?l=en&a=view

[10] http://opensolaris.org/os/community/zfs/docs/

[11] http://foss-boss.blogspot.com/2008/11/nexenta-can-you-say-solabuntu-part1.html