L’actualité du noyau est toujours abondante et notamment en ce moment avec la compétition acharnée entre les deux principaux ordonnanceurs de tâches proposés en remplacement de l’actuel de la série des noyaux 2.6. La situation en est à un point que Linus, lors de l’annonce sur la sortie du noyau 2.6.21, termine son mail par "We now return you to your regular scheduler discussions" ("Nous vous laissons maintenant à vos discussions habituelles sur l’ordonnanceur") ou encore qu’Andrew Morton plaisante en suggérant "or we could move all the Reiser4 code into kernel/sched.c – that seems to get people fired up." ;) ("ou bien nous pourrions déplacer tout le code de Reiser4 dans kernel/sched.c – il semble que cela remplit les gens d’enthousiasme."). La première brève est tout naturellement consacrée à cela en expliquant plus particulièrement le fonctionnement de l’ordonnanceur Staircase Deadline de Con Kolivas (nous reviendrons dans un prochain numéro sur le Completely Fair Scheduler d’Ingo Molnar). Nous terminons ce numéro avec un résumé sur le Linux Storage & Filesystem Workshop s’étant tenu les 12 et 13 février 2007 à San José en Californie.

[TECHNIQUE] La refonte de l’ordonnanceur de tâches

L’ordonnanceur actuel de la série des noyaux 2.6 emploie des heuristiques compliquées afin d’accorder un bonus aux processus interactifs qui seraient autrement lésés face aux processus consommateurs de CPU. Ces heuristiques se fondent sur une comptabilisation pour chaque processus du temps pendant lequel ils dorment. Un processus dormant à répétition signifie souvent qu’il effectue des opérations d’entrées/sorties (ces opérations étant une source importante entraînant un réordonnancement) ou du moins qu’il ne se comporte pas de façon "égoïste" en ne consommant pas entièrement son timeslice (c’est-à-dire la tranche de temps d’exécution accordée à un processus) dès que l’ordonnanceur lui en octroie un nouveau.
De plus, l’évaluation de l’interactivité des processus, au travers de ces statistiques sur leur temps de sommeil, s’avère faussée avec un nombre important de processus sur le système. En effet, l’évaluation du comportement d’un nombre important de processus perd en fiabilité lorsque le temps de l’évaluation est borné, ce qui est le cas avec l’ordonnanceur actuel en O(1).
Aussi, établir ces statistiques demande une période d’apprentissage. Plus elle est courte, plus les tâches interactives peuvent être incorrectement identifiées comme des tâches consommatrices de CPU. Plus elle est longue, plus les tâches interactives vont attendre longtemps avant d’obtenir une faible latence d’ordonnancement et un partage équitable du CPU (avec les tâches très gourmandes en CPU).
Ainsi, Con Kolivas a proposé son Staircase Deadline (SD) Scheduler qui, de par sa conception, favorise les tâches interactives sans besoin d’heuristiques. Après deux années de recherche, Con a annoncé sur la LKML, le 4 mars 2007, la première version de son ordonnanceur alors nommé RSDL (Rotating Staircase DeadLine). Après de nombreux tests, certaines charges se sont révélées moins bien gérées avec ce nouvel ordonnanceur qu’avec l’ancien. Le problème vient des applications utilisant la Xlib, effectuant beaucoup d’opérations sur le compte de X en consommant ainsi son timeslice. Ainsi, X est pénalisé ce qui entraîne une baisse d’interactivité des applications de type GUI (Graphical User Interface). Pour pallier ce problème le serveur X doit être "renicé" à -10. Ce genre de solution ne convient pas à tout le monde. Aussi, le 13 avril 2007, Ingo Molnar propose son propre ordonnanceur, nommé Completely Fair Scheduler (CFS). Depuis, ces deux solutions ont évolué afin de répondre le plus efficacement possible à la problématique de l’ordonnancement de tâches.
Dans la suite de cette brève, nous expliquons uniquement le fonctionnement de l’ordonnanceur SD (en faisant quelques brefs rappels sur la structure de l’ordonnanceur actuel, car beaucoup de ses éléments sont repris dans SD). Nous reviendrons sur l’ordonnanceur CFS dans un prochain numéro, sachant qu’il est en instance d’être l’ordonnanceur qui remplacera l’actuel.

Le Staircase Deadline (SD) CPU Scheduler

L’ordonnanceur SD est conçu afin de choisir en O(1) une tâche à exécuter (l’ordonnanceur actuel se comporte également de cette manière). Son architecture empêche la survenance de famine. Il impose de plus un partage équitable du ou des processeurs disponibles, fondé sur la priorité statique attribuée via la commande nice. Son design ne repose pas sur l’estimation de l’interactivité (coûteuse en CPU) des tâches s’exécutant. Cette estimation est souvent utilisée (et notamment dans l’ordonnanceur actuel) afin d’attribuer un bonus d’exécution aux tâches qui dorment souvent (c’est-à-dire attendant des évènements) correspondant la plupart du temps à des tâches interactives. Ce bonus est accordé afin que ces tâches ne soient pas lésées face aux tâches fortement consommatrices de CPU. Cependant, cette estimation prend du temps. C’est pourquoi, elle utilise des heuristiques sur l’ensemble des échantillons collectés afin d’accélérer le traitement. Il en résulte une mécanique complexe, difficile à maintenir et non prédictible. SD n’effectue pas d’estimation. Il comptabilise la consommation d’un quota d’exécution accordée à chaque tâche en fonction de sa priorité statique (c’est-à-dire celle accordée via nice). Lorsque le quota d’une tâche est consommé, elle descend une marche de "l’escalier" (staircase) des priorités et se voit attribuer un nouveau quota. Lorsque tous ses quotas ont été consommés, une tâche se retrouve finalement privée du processeur jusqu’à ce que toutes les autres tâches aient consommé les leurs. Ainsi, le calcul de comptabilisation, non fondé sur des estimations, et ce mécanisme répondant à la problématique de famine, assurent la prédictibilité de cet ordonnanceur quant à l’échéance maximale avant l’exécution d’une tâche. Notons que l’escalier descendu par les différentes tâches peut varier en nombre de marches (c’est-à-dire en nombre de priorités dynamiques dans lesquelles la tâche va s’exécuter) en fonction de la priorité statique de la tâche. Plus la tâche est prioritaire, plus le nombre de marches est important. Ainsi, une tâche de nice 0 descendra 19 marches alors qu’une tâche de nice 10 (c’est-à-dire de priorité plus faible) descendra seulement 9 marches. Cela assure un bien meilleur temps de réponse pour les tâches de priorité supérieure via la diminution du temps de latence moyen.
Donnons quelques précisions sur le fonctionnement de cet ordonnanceur. Il reprend globalement les structures principales de l’actuel. Ainsi, à chaque processeur est affecté une runqueue listant l’ensemble des processus dans deux tableaux de 40 entrées (de 0 à 39) correspondant aux priorités dynamiques des processus. La priorité dynamique la plus élevée correspond à l’entrée 0. Parmi ces deux tableaux, l’un stocke les processus actifs (active array) et l’autre les processus ayant consommés tout leur quota d’exécution (expired array). Une fois que tous les processus se retrouvent dans le tableau "expiré", les deux tableaux sont permutés, marquant (selon la terminologie de l’ordonnanceur SD) le passage d’une époque majeure à une autre.
Le fonctionnement est ensuite assez simple. L’ordonnanceur fournit la ressource d’exécution (c’est-à-dire la CPU) au premier processus trouvé sur la première ligne du tableau actif contenant au moins un processus (il s’agit d’un des processus de plus haute priorité). Le processus s’exécute alors jusqu’à consommation de son quota qui correspond à sa tranche de temps (timeslice) ou jusqu’à préemption d’un autre processus de priorité supérieure venant de se réveiller (à cause d’une interruption) ou encore jusqu’à ce qu’il cède volontairement le processeur (c’est-à-dire qu’il est en attente d’une ressource d’E/S ou qu’il s’est endormi). Supposons ce dernier cas et aussi qu’aucun processus de priorité supérieure n’est apparu (et n’apparaîtra par la suite, par souci de simplification). L’ordonnanceur va alors choisir le processus suivant dans la même ligne du tableau actif que celui qui vient de s’exécuter. Supposons que ce processus effectue des calculs en continu. Il va consommer tout son quota et ensuite monter d’un cran dans le tableau actif (c’est-à-dire qu’il est ajouté à une ligne de priorité plus faible du tableau ; il descend une "marche" de l’escalier des priorités) avec un nouveau quota à consommer, laissant alors s’exécuter les processus des lignes d’avant dans le tableau. Finalement, une fois qu’il atteint la dernière entrée du tableau, il est placé dans le tableau "expiré" dans la ligne de sa priorité initiale.
Supposons à présent que se réveille notre premier processus qui avait cédé le processeur avant consommation de l’intégralité de son quota. Il va alors être placé à la fin de la file des processus de la ligne de priorité sur laquelle il se trouvait avant de s’endormir (sur une même ligne de priorité, l’ordonnancement se fait suivant une politique Round Robin).
Revenons sur la "descente" de l’escalier. Nous avions dit que le nombre de marches pour une tâche dépendait de sa priorité statique. Voyons maintenant le détail sur cela.
Toutes les tâches, avant d’être rangées dans les tables (active ou "expiré") de l’ordonnanceur, sont pourvues d’un quota d’exécution. Il est calculé en fonction de leur priorité statique (c’est-à-dire de leur nice), à partir de la variable RR_INTERVAL (RR pour Round Robin) qui est positionnée à 8 ms et est augmentée légèrement et progressivement avec le nombre de processeurs présents sur la machine (cette valeur peut aussi être modifiée via /proc). Les processus, de nice supérieur à 0, se voient allouer un quota égal à RR_INTERVAL divisé par 2. Ce quota augmente progressivement pour les processus de priorité statique supérieure (c’est-à-dire de -1 à -20). Cette valeur est stockée pour chaque processus dans leur descripteur au sein du champ quota.
Quand un processus est inséré dans la table active de l’ordonnanceur, la fonction recalc_task_prio teste si le processus a déjà été exécuté à cette époque majeure (chaque processus conserve le numéro de la dernière époque majeure dans laquelle il s’est exécuté), c’est-à-dire avant une rotation des tableaux actif et "expiré". Quatre possibilités sont alors envisageables.
Si le processus n’a pas été exécuté durant cette époque, il va alors être ajouté à la ligne du tableau actif associée à la priorité correspondant à la première cellule libre de la ligne numéro "sa valeur de nice" d’une matrice de priorité sur laquelle nous revenons par la suite. Le processus se voit alors positionner son champ time_slice à quota. La priorité dans laquelle il va s’exécuter est alors conservée afin que la procédure de descente de "marche de priorité" s’effectue correctement. Pour cela, le processus dispose d’un champ de bit bitmap identique à la ligne correspondant à son nice dans la matrice de priorité et étant, ainsi, large de 40 bits (1 bit pour chacune des priorités). Les priorités sur lesquelles le processus s’est exécuté sont ainsi positionnées à 1.
Si le processus s’est exécuté durant cette époque et que son champ time_slice n’est pas vide, il est alors placé de nouveau sur le tableau actif, mais sans l’ajout d’un nouveau quota.
Si le processus s’est exécuté durant cette époque et que son champ time_slice est vide, il va alors chercher la priorité suivante (c’est-à-dire inférieure) et libre dans laquelle il ne s’est pas encore exécuté (via son champ bitmap). Son champ time_slice est alors rempli avec un nouveau quota complet et il est inséré dans le tableau actif à la ligne de sa nouvelle priorité.
Finalement, si le processus s’est exécuté durant cette époque, que son champ time_slice est vide et que son champ bitmap est rempli, alors ce dernier champ est repositionné à la ligne correspondante de la matrice de priorité et le processus est inséré à sa plus haute priorité dynamique, mais dans le tableau "expiré".
Voyons à présent comment est constituée cette matrice de priorité. Pour un processus donné, la lecture se fait horizontalement. Les slots à 0 correspondent aux priorités dynamiques (c’est-à-dire "les marches de l’escalier") dans lesquelles un processus d’une certaine valeur de nice va s’exécuter au long d’une époque majeure. Cette matrice est constituée de telle sorte que le tableau actif (et "expiré") soit équilibré, minimisant ainsi les temps de latence.

PRIORITY: 0..................20.................39

nice -20  0000000000000000000000000000000000000000
nice -10  1000100010001000100010001000100010010000
nice   0  1010101010101010101010101010101010101010
nice   5  1011010110110101101101011011010110110110
nice  10  1110111011101110111011101110111011101110
nice  15  1111111011111110111111101111111011111110
nice  19  1111111111111111111111111111111111111110

Nous voyons ici qu’un processus de nice -20 s’exécute dans toutes les priorités alors qu’un processus de nice 19 s’exécute seulement dans une priorité lors d’une époque majeure.
Nous l’avons dit en début de brève, cet ordonnanceur ne sera probablement pas celui à remplacer l’actuel. Son évolution, cependant, continue toujours afin de "concurrencer" CFS pour que ce dernier puisse avoir un partenaire avec qui se comparer et ainsi être amélioré par la communauté des développeurs du noyau. Alors que SD reprend beaucoup de l’ordonnanceur actuel, CFS met fin à l’utilisation du couple des tableaux actif et "expiré", et s’appuie sur une toute autre structure de données : un arbre équilibré de type red-black tree. Nous reviendrons sur cela dans un prochain numéro.

[Actualité] Linux Storage & Filesystem Workshop 2007 et digressions

L’actualité des systèmes de fichiers sous Linux a été riche ces derniers mois, démarrant par la rencontre Linux Filesystem Workshop qui s’est tenue les 12 et 13 février 2007. Cet événement annuel réunit un petit nombre de développeurs noyau et est sponsorisé par des grands noms : Oracle, Network Appliance et EMC (solutions de stockage), Seagate (disques durs)... D’autre part, avec les récents débats apparus sur la LKML concernant Reiser4 et ZFS, c’est l’occasion de faire un point sur le sujet.

LibAta , erreurs et matériels

Le Filesystem Workshop a été l’occasion de mener plusieurs discussions, dont une partie sur la libAta générique introduite dans le noyau 2.6.19. La partie PATA a été développée pour remettre à plat la gestion des périphériques de stockage IDE, et est en constante amélioration (débogage, ajout de matériel supporté et de fonctionnalités). Un bilan positif a été fait de la partie SATA, notamment sur ses performances et sa gestion des dernières technologies (NCQ, FUA, CompactFlash). Si la libAta utilise la couche SCSI pour la gestion et la remontée d’erreurs notamment, il a été évoqué de les rendre indépendantes, la gestion des erreurs de la libAta étant maintenant jugée plutôt bonne. Le débat a été ouvert sur la gestion d’autres catégories d’erreurs : comment le système de fichiers doit-il se comporter lorsqu’un volume SAN (volume distant connecté par fibre optique) est indisponible, qu’une clef USB est retirée de manière inattendue ou qu’un disque d’un groupe en RAID5 lâche ?
La manière de gérer et d’exploiter au mieux les nouveaux disques dits "hybrides" ou "HHDD" a été abordée. Ces matériels embarquent une mémoire de type Flash (non volatile) en plus du disque dur proprement dit, ce qui peut permettre de réaliser des économies d’énergie ou d’augmenter les performances. Plusieurs possibilités s’offrent : placer toutes les métadonnées du FS dans ce cache, l’utiliser pour effectuer les écritures pour éviter d’utiliser trop souvent le disque qui est gourmand en énergie, y stocker le journal d’un FS... La question de savoir quel sous-système du noyau doit assurer le pilotage de ces caches a été posée. Actuellement, seul Windows Vista sait utiliser ces matériels.

Limitations en volumétrie et ext4

Débattue lors de la précédente édition du LSF, la problématique de la taille maximale de volumes supportée par les systèmes de fichiers a amené à la création de la quatrième version d’Extended Filesystem, soit ext4 (cf. Kernel Corner 86). Pour rappel, le numéro d’un bloc est stocké dans un entier 32 bits (31 utilisés en pratique) sous ext3, et la couche d’abstraction générique aux systèmes de fichiers de Linux, VFS, stocke les numéros d’inode également sous 32 bits. En pratique, ces choix limitent la taille d’une partition à 8 To. Passer à un stockage des numéros de bloc sur plus de 32 bits aurait amené des changements trop profonds dans ext3. Un consensus entre développeurs a donc abouti à la décision d’ouvrir une nouvelle branche d’ext, nommée ext4dev pour l’instant. Les numéros de blocs sont stockés sur 48 bits, repoussant la limite théorique de taille à 1024 PB. La création d’un système de fichiers distinct d’ext3 est également l’occasion d’ajouter des fonctionnalités et d’améliorer les performances. Si les caractéristiques définitives de ce qui deviendra ext4 ne sont pas encore figées, on sait d’ores et déjà que ce ne sera pas une révolution, mais une évolution en douceur. On notera tout de même en particulier les fonctionnalités/technologies suivantes (qui seront incluses ou très probablement incluses) :

• L’apparition d’une structure appelée "extent", décrivant l’emplacement des données physiques sur le disque. C’est une structure beaucoup plus efficace pour désigner les blocs contenant les données de moyens et gros fichiers. Rappel : actuellement sous ext2/3, si un fichier dépasse la taille de 48 Ko, l’emplacement de ses blocs de données sur le disque sera décrit via un pointeur de l’inode renvoyant sur un bloc intermédiaire, contenant lui-même les adresses des prochains blocs hébergeant les données dudit fichier ; si on dépasse 4 Mo, l’inode contiendra un pointeur vers un autre bloc de pointeurs de bloc, chacun d’entre eux décrivant des blocs de données... On imagine le coût de cette structure pour l’accès aux gros fichiers. L’option extent sera désactivable, ce qui permettra de monter une partition ext3 en ext4 ; une fois activée, cette rétro-compatibilité sera perdue.
• Le support de plus de 32000 sous-éléments par répertoire.
• De nouveaux modes d’allocation des blocs de données devraient faire leur apparition. Typiquement, quand une application souhaite créer et écrire dans un fichier, le noyau se charge aussitôt de réserver un bloc sur le disque à cet effet. Cette méthode peut ne pas être la plus optimale : si l’application doit écrire un certain volume de données, le noyau doit, au fur et à mesure qu’il reçoit des données à écrire, réserver d’autres blocs. N’ayant pas pu anticiper suffisamment la quantité de données à écrire, il peut avoir choisi de réserver les blocs à un emplacement n’ayant pas assez de blocs contigus libres ; il est alors obligé d’en choisir ailleurs pour continuer la sauvegarde du fichier, mais celui-ci sera alors fragmenté, entraînant les problèmes de performance que nous connaissons bien. Autre cas fréquent : les applications peuvent avoir besoin de créer des fichiers à durée de vie très brève ; actuellement une réservation systématique de blocs est effectuée. La technique d’allocation tardive (delayed allocation) peut effectuer la réservation de plusieurs blocs à la fois, ce qui offre deux avantages : cette opération est effectuée moins fréquemment et réserve d’un coup le plus de blocs contigus possible, étant donné qu’on a cette fois une meilleure idée de la quantité d’informations à écrire ; en conséquence, on réduit du même coup la fragmentation de fichier. Dans le cas d’un fichier temporaire, il peut n’avoir pas été nécessaire du tout d’effectuer l’opération s’il a été créé et supprimé en très peu de temps. Techniquement, l’allocation des blocs serait effectuée lors de l’appel writeback() plutôt qu’à chaque prepare_write(). Un consensus reste à trouver pour savoir si ceci doit être implémenté au niveau FS (ici donc ext4) ou généralisé à VFS.
  L’allocation persistante (persistent allocation) est une technique permettant de réserver à l’avance un espace défini de blocs contigus pour un fichier ; ceci permet d’éviter la fragmentation, et de garantir dès le départ que l’écriture pourra être réalisée (espace suffisant). Elle devrait être implémentée et utiliser des extents non initialisés à l’avance : ils seraient créés et marqués d’un statut spécial, ce qui diffère des solutions déjà existantes qui pré-remplissent les blocs de zéros (coûteux). À noter que l’allocation persistante a une fonction posix_fallocate() définie par la norme POSIX, mais non implémentée sous Linux ; des discussions pour l’ajouter sont en cours suite à un patch d’Amit Arora (IBM).
• Certainement, le support de dates de création/modification/accès dites "à haute résolution" (nanoseconde), afin de pallier les problèmes pouvant se poser par exemple sur des fichiers auxquels plusieurs applis sont susceptibles d’accéder à de très courts intervalles de temps.
• En cours de développement : défragmentation en ligne (sur système de fichiers monté).

D’autres fonctionnalités, discutées et évoquées dans Kernel Corner 86 à l’issue du précédent Filesystem Workshop, ne seront vraisemblablement pas intégrées (snapshots, undelete, checksums...). L’endroit officiel pour rester in sur l’actualité d’ext4 est http://ext4.wiki.kernel.org. Pour des précisions sur le travail ayant abouti au stockage des indices de blocs sur plus de 32 bits et aux extents, n’hésitez pas à vous reporter à l’article de Laurent Vivier (Linux Mag 90, janvier 2007).

Vérification d’un FS et ChunkFS

Point déjà soulevé lors du LSF workshop 2006 et dans votre Kernel Corner 86, le problème du temps de vérification d’un système de fichiers, qui croît à mesure que les capacités de stockage augmentent, est revenu dans le débat : le temps d’exécution d’un fsck commence à devenir prohibitif. Malgré l’apparition de la journalisation avec ext3, et les équivalents existant sous d’autres systèmes de fichiers, des problèmes subtils (certains crashs brutaux, bugs de l’OS, problème physique sur le disque) peuvent entraîner la nécessité d’effectuer une vérification approfondie via fsck. Concrètement, l’outil doit traverser toute la structure de la partition pour vérifier la cohérence des métadonnées (un bloc de données est-il bien référencé par un inode ?, etc.). La quantité d’informations à analyser, et donc le temps d’exécution, sont directement liés à la quantité de données présentes.
Valerie Henson (ayant travaillé auparavant sur l’architecture de ZFS) travaille actuellement à trouver des solutions pour qu’un système de fichiers nécessite le moins de temps possible pour être remis dans un état cohérent suite à un crash. Arjan van de Ven (Intel) a lancé l’idée que si le temps de vérification croit avec la taille d’un système de fichiers, pourquoi ne serait-il pas découpé, en interne, en plusieurs petites unités de systèmes de fichiers ? De là est né ChunkFS, littéralement "système de fichiers en morceaux". Ainsi, une partition est un ensemble de sous-éléments de taille modeste (quelques centaines de Mo ou 1Go), ayant chacun leurs numéros d’inode et leur superbloc. Afin de pouvoir stocker de gros fichiers (taille > 1 chunk), Val Henson imagine une structure appelée "continuation inode" : le fichier dispose d’un inode sur le premier morceau et d’un autre sur chaque morceau qu’il est nécessaire d’utiliser pour le stocker. L’inode des morceaux suivants contient un marqueur indiquant qu’il est la "suite" de l’inode d’un morceau précédent, et un pointeur vers cet inode précédent. Chaque inode ayant une "suite" contient un marqueur indiquant l’emplacement de l’inode décrivant la partie suivante du fichier. Une implémentation à des fins de recherche est en cours ; actuellement le format sur le disque est ext2.

Débats autour de Reiser4 et ZFS

Le statut de Reiser4, resté au point mort depuis quelques mois, refait surface sur la LKML. Plusieurs partisans de ce FS ont réclamé son inclusion dans le noyau. Andrew Morton y a apporté une réponse plutôt favorable ; jusqu’à maintenant, l’audit du code incomplet et la situation judiciaire de son auteur, Hans Reiser, avaient bloqué toute avancée. Cependant, deux développeurs de Namesys, la société de Reiser, se sont déclarés prêts à assurer la maintenance du code sur leur temps libre. Ils ont déclaré vouloir corriger quelques bugs et travailler encore sur quelques modifications (support des attributs étendus, taille de bloc non fixée à 4 k) avant de demander à nouveau officiellement une inclusion dans la branche officielle de Linux. Au final, le cas de Resier4 a également reçu le soutien du développeur Andi Kleen (développeur noyau chez Suse/Novell).
Le cas de ZFS est également régulièrement évoqué sur cette même LKML. Disposant d’atouts indéniables (copy-on-write, contrôle logiciel de la validité des données écrites...) et d’une grande simplicité d’administration, ce système de fichiers pose cependant deux problèmes majeurs à la communauté Linux : son organisation fait qu’il est à la fois un gestionnaire de redondance (RAID), un système de fichiers physique (format sur disque), un gestionnaire de volumes. Il n’est pas possible de l’inclure dans Linux sans violer l’organisation actuelle de la partie FS : les systèmes de fichiers physiques d’un côté, la gestion du RAID logiciel indépendante d’un autre et, enfin, la gestion de volumes générique (LVM). Le fait que ZFS empiète sur ces 3 domaines à la fois est vu comme une erreur de design par les développeurs noyau Linux. Enfin, la licence et les brevets déposés par Sun sur ce FS rebutent le monde Linux : la CDDL est incompatible avec la GPL et, si Sun a placé des parties de ZFS sous GPLv2, il s’agit principalement du code minimal permettant de lire une partition ZFS (afin que le gestionnaire de boot GRUB soit compatible avec OpenSolaris, d’après Theodore Tso). Il semble donc peu probable que ZFS soit utilisable sous Linux autrement que via FUSE, ce qui pénalise les performances.
Le monde des systèmes de fichiers est donc bouillonnant d’idées en cette période. Cependant, on peut remarquer que tous ces concepts et caractéristiques novateurs sont éparpillés parmi les FS, et qu’aucun n’en propose vraiment un ensemble complet. Pour tenter d’y voir clair, tentons de synthétiser les caractéristiques principales faisant le fort de quelques-uns d’entre eux, ainsi que leurs points faibles, dans le tableau ci-après. Nous ne présentons que les systèmes de fichiers dits "génériques" et décrits précédemment. Étant donné sa popularité et les débats qu’il soulève sur la LKML, ZFS figure à titre de comparaison.