Sun vient de placer sous opensolaris son nouveau système de fichiers ZFS ( http://www.opensolaris.org/os/community/zfs ). Si la fiabilité et les performances sont à la hauteur des fonctionnalités annoncées, c'est un produit (presque) révolutionnaire :
* pool de stockage
* Copy on write (pour assurer la cohérence du FS)
* Checksum sur tous les blocs
* Protection et auto correction contre la corruption de données (raid et checksum)
* Snapshots et clones
* Backup et restauration des données sur snapshots
* Réorganistation et batch des IO
* 128bits d'adressage
Une doc en PDF : http://www.opensolaris.org/os/community/zfs/docs/zfs_last.pd(...)
De plus à regarder les docs, l'administration parait trés tres simple en regard de ce que l'on peut rencontrer avec d'autres combinaisons de FS + LVM.
Journal ZFS
19
nov.
2005
# Je sais pas si c'est propre
Posté par un_brice (site web personnel) . Évalué à 1.
D'autant plus qu'il viennent avec leur outil spécifique (zpool) qui sert à en administrer les fonctionalités, incluant par exemple le RAID et des systèmes complexes de sauvegarde.
Ça peut avoir l'air sympa, mais j'imagine mal la galère avec un utilitaire pour gérer le RAID de reiserfs qui serait diffèrent de celui de ext3.
Et par dessus ça y'a des trucs genre qui risquent encore d'être très laids (si par exemple le système de fichier intègre un lien particulier avec NFS seulement, quid des autres ?).
Mon impression c'est qu'on dirait vraiment du "quick and dirty", lourd à maintenir et adapté seulement au taches les plus courantes. Ceci dit j'ai pas encore zieuté le code, donc ça se trouve je me trompe du tout au tout.
[^] # Re: Je sais pas si c'est propre
Posté par Cook Captain . Évalué à 7.
... "quick and dirty", lourd à maintenir
Si tu lis les manpages et les docs, ce n'est absolument pas l'impression que cela donne. J'ai personnellement jamais vu un fs aussi complet et autorisant une gestion aussi fine (et pourtant j'ai administré pendant qq années des systèmes NetApp, IBM et Linux)
Au sujet de sharenfs, lis les docs (au moins le lien PDF) et tu verras que l'on peut créer autant de point montage souhaités en dessous de home et leur affecter leurs propres propriétés avec une notion d'héritage. C'est au contraire ultra propre et puissant.
[^] # A coté de la plaque.
Posté par un_brice (site web personnel) . Évalué à 5.
Comme beaucoup d'autres.
Un gars compare le nombre de lignes de code dans deux projets.
Je ne vois pas le rapport avec une reflexion sur le design d'un FS. Par exemple, un système monolitique fait presque toujours moins de lignes qu'un système "cloisoné".
On peut y voir qu'ils ont scindé leur code en fichiers, situés dans des dossiers. Très bonne idée. Y'a même un graph des includes, ça doit aider à la lecture du code.
Tu crois que je les tire d'où mes exemples ?
Essaie d'être plus méthodique.
Ce que je critique c'est justement le fait que certaines choses ne devraient pas faire partie du FS pour des raisons que j'explique.
Et toi tu me réponds à partir de tes "impressions" de "clean" a partir des encarts publicitaires de Sun.
Je ne parle pas du nombre de fonctionalités implementée, mais de la manière dont elle le sont.
Sinon, tu pourrait développer ? Qu'est-ce que ce système permet que tu ne sait pas faire autrement ?
Si tu l'avais lu tu saurais que c'est de là que je tire mon example de sharedfs (page 25).
Je dit pas ça pour te vexer mais j'aimerais une argumentation rationelle (avec des arguments relié par des connecteur logique), pas des liens vers les pages de solaris. Et aussi que tu comprenne la nature de ma critique : je ne dit pas que ZFS ne vas pas te faire gagner du temps, mais que je n'aime pas le design.
Ou alors y'a des choses que tu m'a pointée du doigt mais que je n'ai pas su voir.
[^] # Re: A coté de la plaque.
Posté par Cook Captain . Évalué à 6.
Ou sont tes arguments rationnels dans tes explications?
>Ce projet a déja nécessité 5 ans de développement
Comme beaucoup d'autres...
Comme tu parlais de "quick & dirty", il me semblait que c'etait tout de même un argument rationnel.
A partir du moment ou l'intégration du FS+LVM est capable de donner plus pour le même prix, je ne vois pas le pb. Il me semble que Linus T. partage la même opinion (Linux Kernel vs micro noyau). Je ne dis pas que c'est mal du faire du micro noyau, ni des sytèmes modulaires, (c'est même généralement une bonne solution), mais ce n'est pas sytématiquement la panacée. (perte de performance et de flexibilité.)
Maintenant si tu connais un seul système FS+LVM capable de donner autant, cite le moi. Le seul produit qui s'en rapproche amha est veritas LVM/FS ou WAFL et ni l'un ni l'autre ne propose autant de fonctionnalités (sans compter leur complexité -veritas- et leurs prix - les 2).
[^] # Re: A coté de la plaque.
Posté par Larry Cow . Évalué à 3.
Le monsieur te dit justement qu'il émet quelques réserves sur le principe d'avoir FS+LVM livrés "tout en un", il me semble.
[^] # Re: A coté de la plaque.
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: A coté de la plaque.
Posté par fabien . Évalué à 2.
Mais simplement pour te faire ermarquer que (alors que tu parle d'argumentation avec des connecteurs) j'ai du mal a suivre ton raisonement.
Tu ecris :
mais la ligne suivante tu dis :
qui est un peu en contradiction.
tu critique quoi finalement ?
le fond (les fontionalités qui "ne devraient pas être là" : 1ere phrase) ?
ou la forme (la "maniere dont elle le sont" : 2eme phrase) ??
encore une fois je ne dis pas que tes argument ne tiennent pas la routes, mais tu te contredis carrement d'une phrase sur l'autre.
comment nourir le troll^w^w^w^w la conversation si t'es pas clair ?
[^] # Re: A coté de la plaque.
Posté par un_brice (site web personnel) . Évalué à 1.
Les fonctionalités de la phrase deux sont pour moi celles de l'OS (la redondance par exemple), qui selon moi ne devraient pas êtres des mécanismes dépendant du système de fichier (phrase un).
Pour synthétiser : je pense que certaines choses ne devraient pas faire partie du FS (phrase un), que ces choses devraient être implémentées ailleurs (phrase deux), mais que je ne cherche pas à en discutter le nombre puisque c'est une donnée plutôt objective (phrase deux).
À ma décharge: c'est plus clair quand on prends la phrase dans son contexte.
(sinon c'est ^h pour effacer une lettre, ^w supprime des mots)
[^] # Re: A coté de la plaque.
Posté par Cook Captain . É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.
[^] # Re: A coté de la plaque.
Posté par un_brice (site web personnel) . Évalué à 2.
Si j'ai bien compris, il suffit de faire
# vgextend my_volume_group /dev/hdn
pour ajouter le nouveau disque (/dev/hdn) puis
#lvextend -L+1G /dev/my_volume_group/mysfs1
#lvextend -L+2G /dev/my_volume_group/mysfs2
pour ajouter de la place aux éventuelles "partitions logiques" (respectivement 1 et 2 gigas)
et enfin
resize_reiserfs -f /dev/my_volume_group/mysfs1
xfs_growfs /dev/my_volume_group/mysfs2
pour prévenir le fs. Même pas besoin de démonter.
On pourrais facilement imaginer un frontend mais je trouve que le système actuel n'est pas horrible à utiliser.
Si, elles peuvent être réordonées sur la globalité du disque. D'ailleurs elles le sont sous Linux. On peut même attribuer au processus une prioritée dans la file d'attente.
Ça me parrait impossible ce que tu dit : si Linux se comportait comme ça le raid n'aurait aucune utilité.
D'ailleurs le RAID n'est pas géré par LVM, mais par le sous-système de raid, distinct (encore une fois, c'est plus propre).
Renseignement pris, LVM peut même réallouer les blocks défaillants depuis un autre volume.
Désolé d'être un peu condescendant mais... tu est sûr de savoir de quoi tu parle?
Ça ne me convainc pas de l'interêt de ZFS tout ça.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.