Sortie de ZFS 2.3, avec l’extension RAIDZ

 (github.com/openzfs)
1 points par GN⁺ 2025-01-15 | 1 commentaires | Partager sur WhatsApp
  • OpenZFS 2.3.0 inclut comme fonctionnalité centrale RAIDZ Expansion, qui permet d’ajouter de nouveaux périphériques à un pool RAIDZ existant afin d’augmenter la capacité sans interruption de service
  • Fast Dedup améliore fortement les performances de la fonctionnalité de déduplication existante, avec aussi des améliorations de performance dans l’ensemble du code
  • Direct IO permet de contourner l’ARC en lecture/écriture et vise les environnements où le cache peut nuire à l’efficacité, comme avec les périphériques NVMe
  • Ajout d’une sortie JSON optionnelle pour les commandes courantes, prise en charge des noms de fichiers et de répertoires jusqu’à 1023 caractères, ainsi que d’importants correctifs de bugs concernant des problèmes des versions précédentes
  • La prise en charge couvre les noyaux Linux 4.18 à 6.12 et FreeBSD 13.3, 14.0 à 14.2 ; 134 personnes ont participé à ce cycle de publication

Ce qui change dans OpenZFS 2.3.0

  • OpenZFS 2.3.0 apporte des mises à jour centrées sur l’extension du stockage, les performances de déduplication, le chemin d’E/S, le format de sortie des commandes et la prise en charge de noms de fichiers plus longs
  • Le tag de release est zfs-2.3.0 et inclut les changements depuis OpenZFS 2.2.0

Extension du stockage et améliorations de performance

  • RAIDZ Expansion permet d’ajouter de nouveaux périphériques à un pool RAIDZ existant afin d’augmenter la capacité de stockage sans interruption de service
  • Fast Dedup est une mise à niveau majeure des performances de la fonctionnalité de déduplication existante d’OpenZFS
  • Direct IO autorise le contournement de l’ARC en lecture/écriture
    • L’objectif est d’améliorer les performances dans les situations où le cache peut nuire à l’efficacité, comme avec les périphériques NVMe
  • Plusieurs améliorations de performance sont également incluses dans l’ensemble du code

Sortie des commandes et longueur des noms

  • JSON ajoute une sortie JSON optionnelle aux commandes les plus utilisées
  • Long names prend en charge les noms de fichiers et de répertoires jusqu’à 1023 caractères

Stabilité, plateformes et contributions

  • D’importants correctifs de bugs traitant des problèmes signalés dans les versions précédentes sont inclus
  • Plateformes prises en charge :
    • Noyaux Linux 4.18 à 6.12
    • FreeBSD 13.3, 14.0 à 14.2
  • 134 contributeurs ont participé à ce cycle de publication

Documentation et journal des changements

Changements des options de module

  • L’ensemble des options et des éléments qu’elles contrôlent est récapitulé dans la documentation module parameters
  • Les nouvelles options de module incluent des éléments liés à l’extension RAIDZ, au journal de déduplication, à Direct IO, à l’allocator, au scrub et au resilver
    • Exemples : raidz_expand_max_copy_bytes, raidz_expand_max_reflow_bytes, zfs_dio_enabled, zfs_dedup_log_mem_max, zfs_scrub_after_expand
  • Option de module supprimée :
    • zfetch_array_rd_sz
  • Options de module modifiées :
    • zfs_arc_shrinker_limit
    • zfs_bclone_enabled
    • zfs_vdev_disk_classic
    • zio_taskq_write

À lire aussi

1 commentaires

 
GN⁺ 2025-01-15
Avis sur Hacker News

  • La fonctionnalité d’extension RAIDZ de ZFS, préparée depuis des années, est enfin intégrée
    Les principales nouveautés sont l’extension RAIDZ, qui permet d’ajouter des périphériques à un pool RAIDZ existant pour augmenter la capacité sans interruption ; la déduplication rapide, qui améliore fortement les performances de la déduplication d’OpenZFS ; les entrées/sorties directes, qui contournent l’ARC pour améliorer les performances dans des environnements où le cache peut être inefficace, comme avec le NVMe ; la sortie JSON optionnelle pour les commandes fréquemment utilisées ; et la prise en charge de noms de fichiers et de répertoires jusqu’à 1023 caractères

    • Plus précisément, cela signifie qu’on peut ajouter un nouveau périphérique, c’est-à-dire un disque, à un vdev RAIDZ existant
    • Si l’on fait tourner Proxmox sur ZFS et NVMe, je me demande s’il vaudrait mieux activer les entrées/sorties directes lorsque la 2.3 sera déployée
      J’aimerais savoir à quels usages cette fonctionnalité se destine
    • Les quatre premières nouveautés semblent vraiment majeures
    • Cela dit, il faut sans doute considérer que la suppression de vdev reste impossible
    • Je me demande dans quelle mesure cette fonctionnalité a été bien testée avec le chiffrement
      Je me demande aussi si l’équipe ZFS traite réellement le chiffrement comme une priorité de premier rang
      ZFS sous Linux a largement hérité de la réputation de ZFS sous Solaris, mais ceux qui l’utilisent en production doivent examiner assez attentivement le suivi des tickets pour voir la réalité

  • Je ne comprends pas qu’il n’existe toujours pas de réponse à ZFS côté Windows, qui est de loin la plus grande plateforme PC en nombre d’utilisateurs
    Microsoft a eu WinFS, puis ReFS, mais ils ont été relégués au second plan ; le développement continue et certaines parties arrivent parfois dans Win11, mais on ne voit pas de version officielle
    Quelques particuliers tentent le gros chantier de créer une couche de compatibilité ZFS, mais on est encore loin de quelque chose de mûr ou utilisable en conditions réelles
    Je ne comprends pas comment Windows peut encore utiliser un système de fichiers vieux de 32 ans

    • Honnêtement, la situation sous Linux n’est pas beaucoup meilleure
      ZFS a des problèmes de licence avec Linux qui empêchent son intégration complète, et Btrfs est en développement depuis 15 ans mais reste encore en retrait par rapport à ZFS en fonctionnalités et en stabilité
      La plupart des distributions Linux utilisent encore par défaut ext4, vieux de 19 ans, qui est en fait plutôt une extension bâtie sur ext2, du même âge que NTFS
      Pour être juste, peu de composants d’un système d’exploitation sont aussi importants que le système de fichiers, et beaucoup refusent de toucher à un système de fichiers qui n’a pas été éprouvé plus de dix ans en production
    • La raison est simple. La majeure partie de la charge que le système de fichiers devrait assumer est prise en charge par le matériel de stockage d’entreprise sur lequel il repose
      Les baies de stockage gèrent les fonctions nécessaires : snapshots, déduplication au niveau bloc, technologies de stockage objet, RAID/résilience, redimensionnement, etc.
      Les appliances de stockage modernes relèvent presque de la magie noire, si bien que NTFS n’a pas forcément besoin de davantage de fonctionnalités
      On peut y accéder de façon transparente via un NAS/SAN, ou stocker des volumes NTFS sur un boîtier de disques performant
      Dans les usages avancés du monde Linux, il y a Lustre et GPFS, tandis que ZFS convient généralement aux cas où la performance n’est pas le point central, mais où la résilience est nécessaire
    • Le noyau Linux mainline n’a pas non plus d’équivalent à ZFS
      À mon avis, c’est difficile et risqué, et la récompense se limite essentiellement à du respect technique
    • En tant qu’utilisateur final de Windows et Linux qui n’utilise pas ZFS, je me demande ce que je rate
    • OpenZFS pour Windows a atteint le stade de release candidate (rc11), avec encore quelques bugs autour du montage des volumes
      Rien de grave, mais pour l’instant il vaut mieux éviter le chiffrement ; le développement avance vite, avec de nouvelles release candidates toutes les quelques semaines pour corriger les problèmes restants
      En y ajoutant Storage Spaces pour agréger des disques de types ou de tailles différents, et définir l’emplacement, la redondance et la hiérarchisation par Space, Windows devient désormais une plateforme de stockage avancée
      Avec Windows Server, par exemple une édition 2022/2025 Essentials bon marché, on peut aussi utiliser SMB Direct/RDMA sur le LAN et sur des disques durs virtuels .vhdx, avec jusqu’à 10 Gbyte/s de performances, ce qui en fait une alternative plus rapide à iSCSI et sans configuration
      C’est pourquoi j’ai porté napp-it cs, l’interface web GUI pour ZFS, de Solaris vers Windows afin de gérer Storage Spaces, ZFS et des serveurs OpenZFS distants comme Proxmox ; l’usage non commercial est gratuit

  • J’aime le fait que la fonctionnalité d’extension ait été conçue de manière assez conservatrice
    L’extension est non seulement totalement transparente et reprenable, mais elle maintient aussi la redondance tout au long du processus
    Il y a toutefois une petite nuance que les gens doivent connaître
    Même une fois l’extension terminée, les blocs existants conservent l’ancien ratio données/parité. Par exemple, un RAIDZ2 à 5 disques reste réparti sur un ensemble de disques plus grand avec 3 blocs de données pour 2 blocs de parité
    Les nouveaux blocs sont écrits avec le nouveau ratio données/parité. Par exemple, si l’on étend une fois un RAIDZ2 à 5 disques pour passer à 6 disques, on obtient 4 blocs de données pour 2 blocs de parité

    • Je ne suis pas sûr que ce soit vraiment une nuance. Ça veut seulement dire que les anciennes données peuvent rester dans une disposition non optimale
      Mais les avantages de RAIDZ N restent là : le pool continue de fonctionner même si jusqu’à N disques tombent complètement en panne
    • Cette nuance correspond à un comportement tout à fait prévisible. Il faut partir du principe que les fonctionnalités ZFS ne réécrivent généralement pas les blocs existants
      Par exemple, les changements de configuration ne s’appliquent aussi qu’aux nouvelles données
    • Honnêtement, c’est une nuance assez importante
      Da1 Db1 Dc1 Pa1 Pb1
      Da2 Db2 Dc2 Pa2 Pb2
      Da3 Db3 Dc3 Pa3 Pb3
      ___ ___ ___ Pa4 Pb4
      Ici, ___ représente de l’espace libre. Si l’on ajoute un disque pour étendre, on pourrait logiquement s’attendre à quelque chose comme ceci
      Da1 Db1 Dc1 Da2 Pa1 Pb1
      Db2 Dc2 Da3 Db3 Pa2 Pb2
      Dc3 ___ ___ ___ Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Mais d’après ce que je comprends, en pratique l’extension se fait plutôt comme ceci
      Da1 Db1 Dc1 Dd1 Pa1 Pb1
      Da2 Db2 Dc2 Dd2 Pa2 Pb2
      Da3 Db3 Dc3 Dd3 Pa3 Pb3
      ___ ___ ___ ___ Pa4 Pb4
      Ici, les blocs Dd1 à 3 sont simplement gaspillés. Autrement dit, même si l’on ajoute un nouveau disque à la grappe, l’espace de stockage libre n’augmente que de 25 %
      Par exemple, si l’on avait à l’origine 24 To d’espace utilisable total avec des disques de 8 To, et 4 To d’espace libre avant l’extension, alors après l’extension l’espace libre passe à 5 To
      J’aimerais qu’on me dise que je me trompe. Si ce n’est pas une erreur de ma part, cette implémentation me semble assez inutile

  • C’est une grosse nouvelle pour les utilisateurs de ZFS. Probablement surtout pour les amateurs et les usages domestiques, mais ça reste important
    L’extension RAIDZ était l’une des fonctionnalités les plus demandées depuis des années

    • Je ne connais pas encore très bien ZFS et je ne l’ai pas trouvé dans les notes de version, mais je me demande si l’extension ne fonctionne qu’avec des disques de même taille
      J’aimerais savoir si l’on peut ajouter des disques plus grands ou plus petits, ou si tous les disques doivent avoir la même capacité

  • Il s’agit d’une extension en ligne. L’extension elle-même était déjà possible auparavant, mais il fallait arrêter la grappe
    Il était aussi possible de migrer vers des disques plus grands, mais il fallait les remplacer un par un, et bien sûr on ne récupérait la nouvelle capacité qu’après avoir mis à niveau tous les disques
    À ma connaissance, la réduction d’un pool n’est toujours pas possible. Donc si l’on ajoute un 6e disque à un pool de 5 disques, on ne peut plus revenir à 5, même avec très peu de données

  • Enfin !
    Il devient possible de faire une configuration à vdev unique à la limite du raisonnable, comme un RAID-Z3 avec 4 des disques durs les plus chers et les plus denses qu’on puisse acheter aujourd’hui
    Au départ, avec une redondance équivalente à 3 disques, le taux d’utilisation effectif de l’espace n’est que de 25 %, mais à mesure que les besoins en capacité augmentent, on peut acheter un disque à la fois et étendre jusqu’à une douzaine de disques environ
    Avec le temps, le prix des disques baisse, et comme on les ajoute à des moments différents, les probabilités de panne sont aussi réparties

    • C’est vrai, mais il faut aussi voir le commentaire frère
      Étendre la grappe ne rend pas le stockage des données existantes plus efficace
      Pour obtenir le nouveau ratio parité/données, il faut forcer la copie des données puis supprimer l’ancienne version inefficace. Par exemple, il faut un outil de ce genre [1]
      Personnellement, je pense qu’il vaut bien mieux acheter des configurations RAID-Z complètes séparées et ajouter une nouvelle configuration, ou remplacer l’ancienne configuration disque par disque
      [1] https://github.com/markusressel/zfs-inplace-rebalancing

  • Je me demande ce que donne ZFS par rapport à btrfs
    J’utilise actuellement btrfs sur mon serveur domestique, mais j’ai rencontré plusieurs problèmes étranges
    J’envisage de passer à ZFS, mais je n’ai pas envie de me retrouver dans la même situation

    • J’ai essayé btrfs pour la première fois il y a 15 ans, vers Linux 2.6.33-rc4
      Au bout de 3 jours, je me suis retrouvé avec un fichier impossible à supprimer, j’ai donc arrêté de l’utiliser, puis j’ai découvert ZFS plus tard
      ZFS avait aussi quelques problèmes moins graves, mais j’étais alors étudiant en informatique et, comparés à ceux que j’avais rencontrés avec btrfs, ils me semblaient mineurs et corrigeables
      Au cours des 18 mois suivants, j’ai corrigé tous les problèmes qui me gênaient et envoyé des patchs au dépôt ZFSOnLinux de l’époque ; cet effort a contribué à rendre ZFS utilisable en production sous Linux
      Depuis, j’ai continué à utiliser ZFS et il a bien fonctionné
      Si btrfs avait été en meilleur état, je serais devenu contributeur btrfs. Mais non seulement son état était mauvais à l’époque, et même par la suite, chaque fois que je l’ai tenté pour un usage sérieux, des problèmes du genre ENOSPC alors qu’il restait encore de l’espace m’ont régulièrement bloqué
      À l’inverse, ZFS fonctionne, tout simplement. Beaucoup de travail a été fait par moi et par de nombreuses autres personnes pour qu’il fonctionne bien
      La plus grande différence est que ZFS reposait sur des bases très solides, notamment grâce à une excellente infrastructure de tests de régression
      Une version en espace utilisateur exécute le code de façon aléatoire pour trouver les bugs avant qu’ils n’explosent en production, et une batterie de tests est lancée pour chaque changement proposé afin de filtrer les bugs
      ZFS compte aussi plus de personnes qui relisent les changements proposés que les autres systèmes de fichiers. Les développeurs de Btrfs disent souvent eux-mêmes qu’il y a un gros écart d’effectifs entre les deux systèmes de fichiers ; de mémoire, ils parlaient d’environ un facteur 6
      Quoi qu’il en soit, rares sont ceux qui regrettent d’utiliser ZFS, donc il te plaira probablement
    • ZFS est utilisé en production depuis près de 20 ans
      Selon la documentation de BTRFS, BTRFS n’est pas encore totalement adapté à la production : https://btrfs.readthedocs.io/en/latest/btrfs-man5.html#raid5...
      Certains cas d’usage simples peuvent être considérés comme suffisamment mûrs pour la production avec BTRFS, mais les résultats varient selon l’environnement
    • btrfs poursuit des objectifs similaires à ZFS, mais il est beaucoup moins mature
      Je l’utilisais pour la partition racine parce qu’il ne nécessitait pas DKMS, mais j’ai eu beaucoup de problèmes
      Mon usage était assez simple, uniquement en miroir, mais un jour, lorsqu’un des disques de la grappe a eu un problème, btrfs n’a pas correctement encaissé le choc
      De mémoire, il a tout remonté en lecture seule et, avec les réglages par défaut, ne fonctionnait pas en mode dégradé
      Même mdraid, qui n’a pas de fonctionnalités comme les sommes de contrôle, aurait probablement fait mieux
      ZFS marque lui aussi la grappe comme défectueuse, mais il permet évidemment de continuer à l’utiliser
      J’ai perdu confiance parce que le comportement par défaut n’était pas celui d’un RAID, c’est-à-dire que la partie R, celle qui relit les données, manquait pratiquement
      Depuis mon passage à ZFS, je n’ai plus eu de problème, et la communauté comme les bons outils sont aussi bien plus nombreux
    • J’ai utilisé Btrfs pendant quelques années, puis je l’ai quitté il y a quelques années
      Il m’est arrivé une ou deux choses étranges avec Btrfs, mais j’ai toujours fini par pouvoir tout récupérer
      Globalement, j’aimais la flexibilité de Btrfs, mais dans la plupart des cas je le trouvais trop lent
      Aujourd’hui j’utilise ZFS sur Arch Linux et, pour l’instant, je n’ai globalement pas de problème
      Il offre aussi davantage de réglages et de méthodes pour optimiser les performances
      Si je devais donner un conseil, ce serait de bien se renseigner et tester ZFS. Il y a une petite courbe d’apprentissage, mais pour moi, la migration en valait la peine

  • C’est une bonne nouvelle que le contournement de l’ARC ait été ajouté pour les performances NVMe
    ZFS a tendance à ne pas exploiter pleinement le potentiel du NVMe
    L’extension en ligne pourrait aussi être intéressante
    J’ai essayé d’utiliser ZFS pour une base de données très chargée et je me suis fait sévèrement piéger par un bug de fragmentation
    La seule façon de retrouver les performances semblait être de copier les données hors du volume, de supprimer le volume, puis de recopier les données
    Désormais, il sera peut-être possible d’étendre le zpool puis de copier le tablespace au sein du même volume pour réduire la fragmentation

  • Le fait que TrueNAS prenne déjà en charge cette fonctionnalité est aussi intéressant[0]
    Il semble probablement utiliser la 2.3.0rc3 ; je ne sais pas trop ce qu’il en est de la stabilité, mais c’est très prometteur
    https://www.truenas.com/blog/electric-eel-openzfs-23/

  • Quelqu’un peut expliquer pourquoi on utiliserait quelque chose comme ZFS à la maison ?

    • Pour moi, les raisons sont les suivantes
      Sommes de contrôle : à la maison, la qualité du matériel est généralement plus faible, ce qui les rend au contraire encore plus importantes. Il y a beaucoup de raisons pour lesquelles de mauvaises données peuvent être écrites : contrôleurs défectueux, câbles médiocres, disques durs conservés à des températures supérieures aux recommandations, etc. Et ZFS gère bien cela automatiquement s’il y a de la redondance
      Snapshots : très utile pour faire des sauvegardes et revenir rapidement à une ancienne version d’un fichier après une erreur
      Tranquillité d’esprit : comparé aux alternatives, je trouve ZFS facile à utiliser et il est difficile de commettre une erreur qui entraîne une perte de données. Par exemple, si, en remplaçant un disque défectueux, on retire par erreur le mauvais disque et que le pool devient inutilisable, il suffit de le rebrancher pour que tout reparte comme si rien ne s’était passé
      mdadm est peut-être différent aujourd’hui, mais quand je l’ai utilisé il y a quelques années, j’avais toujours peur de faire une erreur destructrice
    • Pour donner une réponse que personne d’autre n’a donnée, ZFS est bien pour stocker des jeux Steam
      Avec recordsize=1M et compression=zstd, on peut souvent stocker environ 33 % de jeux en plus dans le même espace
      Un ami utilise ZFS pour stocker ses jeux Steam sur plusieurs disques durs. Et il a donné à ZFS un SSD en L2ARC
      ZFS met automatiquement en cache sur le SSD les jeux qu’il lance souvent, pour qu’ils se chargent plus vite
      Quand ses jeux préférés changent, ZFS s’adapte automatiquement et les met en cache sur le SSD
    • J’utilise zrepl pour répliquer tout le système de fichiers vers un NAS local toutes les 10 minutes
      Cela m’a déjà énormément aidé une fois quand mon WD_BLACK SN850 est mort soudainement [1]
      Ça m’a aussi permis de récupérer du code perdu à cause d’une erreur git classique
      Perdre des données à cause d’une erreur utilisateur ou de la panne d’un seul appareil ne devrait plus être possible. Nous avons la technologie pour ça
      [1]: https://chromakode.com/post/zfs-recovery-with-zrepl/
    • Il y a plusieurs raisons, mais pour moi les principales sont la fiabilité et la portabilité
      Il n’existe pas d’autre système de fichiers moderne, avec sommes de contrôle et auto-réparation, qui soit lisible et inscriptible sous Linux, FreeBSD, Windows et macOS
      Les snapshots, c’est-à-dire les environnements de démarrage, sont aussi pris en charge par Btrfs. Mon installation Linux l’utilise pour ne pas avoir à me soucier d’un module noyau tiers pour lire le système de fichiers racine
      Les performances ne sont pas excellentes non plus, et si les performances sont votre priorité sous Linux, XFS est un meilleur choix
    • C’est relativement simple, mais puissant
      Avant, j’utilisais MDADM + LVM + dm-crypt + ext4, et ça fonctionnait aussi, mais il y avait trop de couches et c’était pénible
      Les snapshots automatiques sont très simples et rapides
      Quand on supprime un fichier, il est aussi facile d’y accéder : pas besoin de restaurer tout le snapshot, il suffit de faire un cp depuis le dossier caché .zfs/
      Je fais tourner ça depuis des années avec 6 disques de 8 To. C’est du RAIDZ2, donc jusqu’à 2 disques peuvent mourir
      Est-ce que je l’utiliserais sur un disque unique dans un PC de bureau ? Probablement pas