Oracle bloquerait-il l’adoption du ZFS ?

Bah il fallait s'en douter, toutes les technologies SUN seront découpées et vendues petit à petit! Sinon à quoi bon les racheter?

Faut pas s'attendre à des miracles, après tout ORACLE c'est le KRO$OFT de la ligne de commande !

Précision importante, la license interdit de le distribuer en binaire, mais c'est compilable en modulaire chez soi sans problème.

il me semble que c'est oracle qui a créé Btrfs

en même temps quelqu'un l'a porté nativement (pas encore complet)
http://www.osnews.com/story/23416/ [...] _for_Linux

heu... y'a une info dans cette news qui tient pas la route: fuse (qui signifie Filesystem in User SpacE) n'a pas tant d'impact sur les performances que cela, si les pilotes NTFS sous Linux sont une quelconque indication:
- le pilote NTFS intégré au noyau a des capacités limitées, mais est capable de lire et écrire sur disque
- le pilote NTFS chargé via FUSE (ntfs-3g) est beaucoup plus capable (gestion des ACL), mais est essentiellement la base du pilote du noyau; il utilise le module fuse du noyau, et une bibliothèque utilisateur de FUSE réduite.

Sur ma bécane, les deux ont le même taux de transfert et le même taux d'utilisation du CPU - dire que fuse limite les performances n'est absolument pas prouvé. Surtout que NTFS n'est pas un système de fichiers simple:
- gestion de flux parallèles,
- gestion de la défragmentation live
- gestion de la compression et de l'encryptage
- gestion de plusieurs espaces de noms en parallèle
- journalisé
- métadonnées des fichiers en UTF-16.

Et pour ceux qui insistent pour charger un pilote dans l'espace mémoire noyau, y'a toujours dkms - qui permet de compiler un module pour le noyau en fonctionnement automatiquement.

C'est donc vraiment une fausse excuse.

Le vrai problème, c'est que les programmeurs intéressés par ZFS ont préféré bosser sur btrfs (qui est davantage flexible que ZFS avec une architecture de base en théorie aussi efficace), et que ceux qui restent n'ont pas les capacités d'intégrer ZFS dans le noyau sans passer par un chausse-pied et beaucoup de graisse - ils espèrent donc qu'en permettant l'intégration de ZFS dans le noyau, les programmeurs du noyau s'occupent de cette partie.

L'article n'est pas complet.

ZFS sous Linux est une aberration technique, position tenue également par Linus Torvald. Ce système se mêle de ce qui ne le regarde pas en tant que système de fichiers (gestion des volumes et autres) C'est un bloc monotlithique alors que Linux est un système de briques fonctionnelles. Le problème d'intégration n'est donc pas que licence, il est conceptuel. Même avec une licence adaptée peu de chance qu'il rejoigne la ligne de développement officielle du noyau (des systèmes de fichiers autres ont déjà eu ce prix à payer voulant dépasser leur statut de système de fichiers)

Ensuite effectivement btrfs remplie les fonctions utiles de ZFS et est enfin mature. Alors pourquoi tenter de pousser un système non adapté alors qu'il y a plus léger ? C'est un peu incohérent. (Pour information Ubuntu 10.10 Server sera en btrfs) Encore plus quand on sait que le principal fournisseur du développement du code de btrfs est Oracle, donc pousser ZFS revient à se tapper dessus tout seul.

Ensuite on ne compare pas ZFS et NTFS-3g sous Fuse. NTFS-3g a toujours été développé par ce biais, pour ZFS c'est une obligation non voulue et partant d'un portage c'est donc plus lourd comme contexte. Et surtout NTFS-3g ca reste pour du NTFS qui aussi complet (mouarf) puisse-t-il être pour Windows n'a rien d'un système avancé pour serveur (128bits pour ZFS, snapshots, check en live ... tout ca c'est du rêve chez MS) Et donc en utilité sur un serveur (parceque c'est bien là l'utilité de ZFS/btrfs on a une charge bien plus importante de données et calculs de ces fluxs.

Heu je pense que tu devrais tester ZFS sous solaris/nexenta puis sous linux avec fuse avant de parlers... Attention hein zfs est un systeme de fichier qui necessite plusieurs disques avant de pouvoir s'exprimer.
Et btrfs un systeme de fichier mature??? Allo la derniere version doit etre 0.2 n'integre pas le quart des fonctionnalites de zfs

@no_on: ZFS a été conçu pour Solaris (Sun ZFS, Sun Solaris, si tu ne vois pas le lien...); Linux supporte une tripotée de systèmes de fichiers, lesquels dans la mesure du possible tentent de partager les mêmes interfaces et sous-systèmes; ZFS, comme le dit lunarok, tente d'implémenter la totale sans faire attention à ce qui existe déjà.
Pour réellement profiter de ZFS sous Linux, il faudrait le réécrire en intégralité pour qu'il s'intègre au noyau comme les autres pilotes.
Une tâche titanesque lorsqu'on voit le foutoir qu'est ZFS, pour une utilité par rapport à d'autres systèmes de fichiers qui n'est encore, sous Linux, que théorique.
Les développeurs ont donc décidé de se concentrer sur ext4 et btrfs, tâches autrement plus simples:

- ext4 est basé sur un ext3 étendu, une base mûre et suffisamment stable pour être le défaut dans les distros actuelles

- btrfs est basé sur les b-trees - comme ZFS - maisavec une approche différente et simplifiée. OK, il n'est pas fini, mais est vraiment encourageant.

Les deux, cumulés, couvrent 95% des fonctionnalités et performances les plus requises de ZFS (et en ajoutent quelques-unes, comme la prise en charge native des SSD dans btrfs: allocation plus efficace) sans prendre la tête à personne en matière de licence, et peuvent au moins s'intégrer dans le noyau 'vanille' sans réinventer l'eau tiède.

D'où le relatif désintérêt des linuxiens pour ZFS: si c'est gros, que ça tient pas bien, que ça n'apporte pas beaucoup plus que ce qu'on fait déjà, qu'il y a déjà une solution interopérable (FUSE), et que ceux qui en ont vraiment besoin se comptent sur les doigts de la main, pourquoi s'enquiquiner avec?

Rasoir d'Occam, mon p'tit gars; ou sinon, méthode KISS.

"
D'où le relatif désintérêt des linuxiens pour ZFS: si c'est gros, que ça tient pas bien, que ça n'apporte pas beaucoup plus que ce qu'on fait déjà, qu'il y a déjà une solution interopérable (FUSE), et que ceux qui en ont vraiment besoin se comptent sur les doigts de la main, pourquoi s'enquiquiner avec?"

Ha bon? J'ai toujours crus que la logique autour de linux c'était "si je fais pas de la même manière pourquoi je ne le ferais pas?" Mais bon, peut être que ceux qui font le noyau sont moins du genre à réinventer le fil à couper le beurre en disant "je tresse dans l'autre sens alors c'est mieux."

@omega2: si Sun avait proposé un module ZFS, bien intégré dans la structure des systèmes de fichiers du noyau, alors oui; dans l'état actuel des choses, Sun (Oracle) met à disposition le code de l'implémentation Solaris du noyau, laquelle n'a de correspondance avec Linux que le fait qu'elles conforment avec POSIX et qu'elles sont programmées en C(++) - mais c'est aussi le cas de Windows NT - et sans garantie aucune au niveau des brevets et copyrights d'éléments spécifiques dans ZFS, ni même de tests de compatibilité!

Intégrer ZFS tel quel demanderait donc de créer une couche de compatibilité Solaris dans le noyau (ce que fuse et le module existant font dans une certaine mesure) et de ne pas se soucier des brevets, licences etc. spécifiques à Solaris (déjà, rien que ça, c'est niet) ou alors de reprogrammer ZFS du début à la fin, en créant constamment des tests de régression par rapport à un système qui peut changer à tout moment, et qui bosse en plus sur des données, en mode noyau, le tout avec de hautes performances.

C'est comme de vouloir refaire Wine, en y ajoutant une émulation du noyau NT en mode kernel - et sans pertes de performances, avec la docu MSDN comportant les termes: "toute bibliothèque développée compatible avec ces interfaces doit être sous licence CDDL, pas GPL, sinon on lâche les avocats". Tu te sens?

Non?

Les devs de Linux non plus.

mitch074 > Le bout de texte que j'ai cité, je le comprend comme disant "il existe déjà un truc du genre donc on laisse tomber" ce qui me semble quand même assez antinomique de l'historique de l'environnement Linux où les développeurs font et refont tellement de programmes qui se ressemblent que ça en est presque comique par moment.

Tu confonds Linux, GNU et la philosophie UNIX en général. Les trois sont très, très proches (normal), mais il y a une différence. Alors, je résume:

- Linux, le noyau qui peut faire tourner du UNIX sous licence GPL, intègre un maximum de choses venant d'ici ou là, mais c'est juste un noyau: si il y a deux pilotes pour une même carte son, le nouveau sera conservé avec l'ancien jusqu'à ce que l'ancien, devenu inutile, soit supprimé; si les deux sont égaux en matière de qualité, flexibilité et performance mais radicalement différents, un troisième sera écrit jusqu'à ce qu'il cumule les avantages de tous, et les anciens seront supprimés.

On a eu le cas avec le Completely Fair Scheduler: à la base, il s'agit d'un projet proposé par Con Kolivas pour remplacer le scheduler du noyau par quelque chose de plus sympa pour une station de travail. Andrew Morton a réécrit un autre scheduler, basé sur la même idée mais avec une approche trop différente pour être constitué d'un simple patch. Le scheduler de Colivas fut donc abandonné avant de dépasser le stade de patch sur la kernel ML, mais le CFS est 'achement plus réactif que l'ancien.

Pour résumer, dans Linux (le noyau), un composant reste jusqu'à ce qu'un remplaçant se pointe; lorsque le remplaçant aura pris sa place comme élément par défaut, il sera déprécié puis, si plus personne ne s'en sert et la compatibilité garantie, supprimé. Si un élément n'est utilisé par personne, et donc plus maintenu, il sera aussi déprécié puis supprimé.

- GNU est un système d'exploitation compatible UNIX, souvent fourni avec Linux en noyau (ce pourquoi les puristes appellent le système complet GNU/Linux, par opposition avec GNU/Mach, ou GNU/BSD) mais entièrement sous licence GPL. Comme pour Linux, si deux utilitaires ont la même utilité, l'un sera réécrit pour prendre en charge le maximum d'avantages de l'autre, et l'autre sera abandonné. Si les deux ne sont pas fusionnables, c'est qu'ils sont à la base trop différents (approche utilisateur, type de traitement etc.)

GNU contient Emacs; les fans de Vi lui préfèrent vim, mais là c'est une question de préférence. GNU fournit glibc, qui fonctionne très bien en général, mais les utilisateurs de processeurs ARM n'aiment pas les performances de ce dernier, et préfèrent eglibc sur leur plateforme parce qu'il est compatible avec glibc mais est plus rapide.

Le but de GNU est de pouvoir avoir un système UNIX entièrement sous licence GPL; si un utilitaire existe et est maintenu, même peu, il sera conservé parce que "ça peut servir". S'il n'est plus maintenu ou qu'il y a mieux ailleurs, il sera supprimé.

- UNIX est une famille d'OS où chaque outil est supposé faire une seule chose, mais la faire super bien; si deux outils font la même chose, ils seront donc interchangeables dans le système complet. Si un seul outil convient à tout le monde, seul cet outil sera conservé. Note que 'convenir à tout le monde' peut aussi bien être un utilisateur qu'un éditeur de système UNIX qui dit "gmake c'est plus mieux bien que qmake, et si vous êtes d'accord, je vous vends un système avec qmake là de suite" - résultat, on a gmake et qmake, les deux font la même chose, mais les utilisateurs de UNIX1 jurent par qmake, les utilisateurs de UNIX2 jurent par gmake et se f...tent de la g...le des utilisateurs de UNIX1 - qui le leur rendent bien.

Retour à ZFS. C'est un système de fichiers basé sur des B-trees. Il est haute performance, haute disponibilité, haute capacité, etc. il est utilisé sur des machines Sun. c'est un système de fichier pour disque dur, ce qui veut dire que le média doit être physiquement présent dans la machine pour être utilisé.

Je note de suite: combien de personnes s'amusent à monter un disque sous Solaris, puis sous Linux, et de nouveau sous Solaris, et à faire tourner des jobs haute performance dessus?

(on entend les criquets).

Bon, est-il raisonnable de dire que si on veut accéder aux données de ce disque sous GNU/Linux, on peut simplement le faire par réseau? Dans 99% des cas, oui.
Et le % qui reste? la machine Solaris a pris feu et on n'a qu'une machine GNU/Linux sous la main pour récupérer les données du disque dur. Est-il raisonnable de dire que ZFS monté via fuse devrait faire l'affaire, parce qu'on préférerait que le kernel ne plante pas pendant la récup parce qu'un gros blob le prend à rebrousse-poil? Ben, plutôt...

Reste qui? Les p'tits gars qui ont formaté leur disque externe eSATA en ZFS et qui s'en servent pour bouger leurs données?

Mais zut alors, et si j'veux utiliser ce disque sous Windows? Ben pétitionnons Ballmer pour que Windows inclue en série et par défaut un pilote ZFS avec toutes les fonctionnalités et la performance de la version Solaris! Allez!

... Ou j'arrête de faire l'andouille, et je formate ledit disque externe en NTFS, et ça fonctionnera bien sous GNU/Linux, sous Solaris, sous OS X, sous Android, et sous Windows, avec les ACLs, les performances et tout.

Pourquoi sous Linux on s'enquiquine avec ext4? Parce qu'on peut mettre à jour un système de fichiers ext2 en ext3, puis en ext4, sans reformater - pratique pour un serveur qui tourne depuis des années et qu'on veut mettre à jour sans se prendre trop la tête et en étant raisonnablement certain de pas se prendre les pieds dans le tapis. Et btrfs ou ZFS, ils font pas ça.
Bon, pourquoi btrfs? Ben parce que sous Linux, y'a pas de système de fichiers pour SSD, ni qui prenne en charge la compression à la volée, ni le copy-on-write pour versioning des révisions d'un fichier.
Et on remarque aussi que le pilote et les outils pour ext4 prennent le pas sur le pilote et les outils ext3 - lesquels ont déjà viré les pilotes et outils ext2.
Est-il raisonnable de penser que le jour où quelqu'un sort des outils permettant de monter une partition ext2/3/4 avec un pilote btrfs, et de la porter sous ce nouveau schéma, puis de btrfs vers ext2/3/4, les pilotes ext2/3/4 disparaîtront du noyau? Sûrement - s'ils n'étaient pas si fondamentalement différent que c'est impossible.

mitch074, merci!

Un post un peu "monolithique", mais on aimerait plus souvent des intervenants de ton niveau et avec ta pédagogie teintée d'humour.

Tout comme Shymata : merci à mitch pour cet humour dans la clarté (ou l'inverse).