Posté par Cook Captain .
En réponse au journal ZFS.
Évalué à 1.
A la demande générale (!), je vais apporter plus de précisions à ma réponse à la question de Brice "pourquoi les développeurs de ZFS n'ont il pas utilisé un lvm -gestionnaire de volume - traditionnel en le séparant du FS". (comme c'est la cas actuellement dans toutes les architectures).
La réponse brève est : parce ce que n'était pas possible (en pratique).
Juste en préambule, il faut savoir que le volume (géré par le LVM - Logical Volume Manager) est une interface entre le FS et le(s) disque(s). A ce titre, le FS ne sait pas, et n' a pas à savoir, si il attaque un volume logique ou une partition physique du disque. De son coté le volume ne connait rien de la manière dont le FS gére ses données. Il s'assure juste de transmettre les données au disque. L'intéret d'un gestionnaire volume est qu'il permet à un FS de s'étendre sur plusieurs disques (pour effectuer par ex. de la concaténation, du stripe ou du raid).
Prenons qq fonctionnalittés offertes par ZFS.
1. Pool de stockage. Avec un LVM classique, c'est impossible à effectuer. En effet le LVM classique impose une relation 1 FS pour 1 volume. Si on souhaite ajouter de l'espace disque pour deux FS, il devient alors nécessaire de partionner le disque supplémentaire et d'affecter ces partitions à chacun des volumes. C'est ni trés pratique ni trés souple (réservation d'espace statique), mais c'est surtout trés mauvais pour les perfs. (cf. 2). ZFS n'a pas ces contraintes car un volume ZFS peut gérer plusieurs FS peut être assigné à un volume.
2. Performance : Le principe pour avoir de bonne perf sur des IO est relativement simple. Eviter que le disque ne passe son temps à se balader d'un bout à l'autre d'un cylindre. Pour cela, il est nécessaire de réordonner et de cacher les ordres de lecture/écriture de manière intelligente. Dans un système classique, quand vous avez 2 FS qui partage un même disque, vous êtes mort (les caches des FS ne sont pas commun et les io ne peuvent pas être réordonner sur la globalité du disque). Le LVM ne peut en rien améliorer les choses car il doit forcément écrire de manière synchrone sur le disque et n' a évidement pas avoir accès aux structures interne de chaque FS). ZFS est quand à lui est capable de traiter les IO de manière globale pour tout le disque, ce qui lui permet d'optimiser les entrés sorties, car son gestionnaire de volume a accès à toutes les structures du FS.
3. Sécurité en raid soft. Deux disques, c'est mieux qu'un. Et effectuer un checksum sur les blocs permet de sécuriser les données en cas d'erreur sur un disque. Un FS classique associé à un LVM pour le RAID est tout fait capable d'effectuer un tel traitement. Malgré cela, si un FS détecte une erreur de checksum, le FS est incapable de la corriger et renvoie juste une erreur, car le LVM se contente de retourner le bloc qui arrivent en premier d'un des 2 disques (sans savoir que la données est erronée). Pire, en fonction du disque, la donnée pourra être exacte ou erronée et le FS semblera renvoyer de manière quasi aléatoire une erreur. Pour corriger cela il faudrait que le LVM connaisse ... la structure du FS. Ce qui est le cas pour ZFS et qui lui permet de détecter l'erreur mais ausi de la corriger sur le disque défaillant!
Bref, pour générer des perfs max, une sécurité max et une grande souplesse, on s'apercoit rapidement que LVM et FS doivent être fortement imbriqués, car il est nécessaire que toute la structure des données (cache, layout, etc.) soit connu tout du long de la chaine d'entrée/sortie. Il n'y a alors pas bcp d'autre choix que de lier le FS et le LVM en un seul module. (peut-on d'ailleurs encore parler de LVM et de FS?). Ce qui n'exclut en rien les autres FS car ceux-ci peuvent à leur tour être encapsulé dans ce nouveau système (un peu comme IP dans ATM!) à travers une couche de compatibilité.
ZFS n'aurait-il donc que des qualités ? Non : à mon avis, il a un gros défaut : sa jeunesse, j'attendrai au moins un an (voir 2) avant de mettre en prod un système critique avec ce filesystem. Mais, il est tout de même trés prometteur.
[^] # Re: A coté de la plaque.
Posté par Cook Captain . En réponse au journal ZFS. Évalué à 1.
La réponse brève est : parce ce que n'était pas possible (en pratique).
Juste en préambule, il faut savoir que le volume (géré par le LVM - Logical Volume Manager) est une interface entre le FS et le(s) disque(s). A ce titre, le FS ne sait pas, et n' a pas à savoir, si il attaque un volume logique ou une partition physique du disque. De son coté le volume ne connait rien de la manière dont le FS gére ses données. Il s'assure juste de transmettre les données au disque. L'intéret d'un gestionnaire volume est qu'il permet à un FS de s'étendre sur plusieurs disques (pour effectuer par ex. de la concaténation, du stripe ou du raid).
Prenons qq fonctionnalittés offertes par ZFS.
1. Pool de stockage. Avec un LVM classique, c'est impossible à effectuer. En effet le LVM classique impose une relation 1 FS pour 1 volume. Si on souhaite ajouter de l'espace disque pour deux FS, il devient alors nécessaire de partionner le disque supplémentaire et d'affecter ces partitions à chacun des volumes. C'est ni trés pratique ni trés souple (réservation d'espace statique), mais c'est surtout trés mauvais pour les perfs. (cf. 2). ZFS n'a pas ces contraintes car un volume ZFS peut gérer plusieurs FS peut être assigné à un volume.
2. Performance : Le principe pour avoir de bonne perf sur des IO est relativement simple. Eviter que le disque ne passe son temps à se balader d'un bout à l'autre d'un cylindre. Pour cela, il est nécessaire de réordonner et de cacher les ordres de lecture/écriture de manière intelligente. Dans un système classique, quand vous avez 2 FS qui partage un même disque, vous êtes mort (les caches des FS ne sont pas commun et les io ne peuvent pas être réordonner sur la globalité du disque). Le LVM ne peut en rien améliorer les choses car il doit forcément écrire de manière synchrone sur le disque et n' a évidement pas avoir accès aux structures interne de chaque FS). ZFS est quand à lui est capable de traiter les IO de manière globale pour tout le disque, ce qui lui permet d'optimiser les entrés sorties, car son gestionnaire de volume a accès à toutes les structures du FS.
3. Sécurité en raid soft. Deux disques, c'est mieux qu'un. Et effectuer un checksum sur les blocs permet de sécuriser les données en cas d'erreur sur un disque. Un FS classique associé à un LVM pour le RAID est tout fait capable d'effectuer un tel traitement. Malgré cela, si un FS détecte une erreur de checksum, le FS est incapable de la corriger et renvoie juste une erreur, car le LVM se contente de retourner le bloc qui arrivent en premier d'un des 2 disques (sans savoir que la données est erronée). Pire, en fonction du disque, la donnée pourra être exacte ou erronée et le FS semblera renvoyer de manière quasi aléatoire une erreur. Pour corriger cela il faudrait que le LVM connaisse ... la structure du FS. Ce qui est le cas pour ZFS et qui lui permet de détecter l'erreur mais ausi de la corriger sur le disque défaillant!
Bref, pour générer des perfs max, une sécurité max et une grande souplesse, on s'apercoit rapidement que LVM et FS doivent être fortement imbriqués, car il est nécessaire que toute la structure des données (cache, layout, etc.) soit connu tout du long de la chaine d'entrée/sortie. Il n'y a alors pas bcp d'autre choix que de lier le FS et le LVM en un seul module. (peut-on d'ailleurs encore parler de LVM et de FS?). Ce qui n'exclut en rien les autres FS car ceux-ci peuvent à leur tour être encapsulé dans ce nouveau système (un peu comme IP dans ATM!) à travers une couche de compatibilité.
ZFS n'aurait-il donc que des qualités ? Non : à mon avis, il a un gros défaut : sa jeunesse, j'attendrai au moins un an (voir 2) avant de mettre en prod un système critique avec ce filesystem. Mais, il est tout de même trés prometteur.