Ce printemps, nous avons déjà discuté de quelques sujets d'introduction, tels que la façon de vérifier la vitesse de vos disques et ce qu'est le RAID . Dans le second d'entre eux, nous avons même promis de continuer à étudier les performances de différentes topologies multi-disques dans ZFS. Il s'agit du système de fichiers de nouvelle génération qui est implémenté partout: d' Apple à Ubuntu .

Eh bien, aujourd'hui est le meilleur jour pour découvrir ZFS, lecteurs curieux. Sachez simplement que, selon une évaluation prudente du développeur d'OpenZFS Matt Arens, "c'est vraiment compliqué".

Mais avant d'en arriver aux chiffres - et ils le feront, je le promets - pour toutes les variantes de configuration de vosmidiskovoy ZFS, vous devez parler de la façon dont ZFS stocke les données sur le disque.

Zpool, vdev et appareil

Ce diagramme de pool complet comprend trois vdev auxiliaires, un pour chaque classe et quatre pour RAIDz2.

Il n'y a généralement aucune raison de créer un pool de types et de tailles de vdev inappropriés - mais si vous le souhaitez, rien ne vous empêche de le faire.

Pour vraiment comprendre le système de fichiers ZFS , vous devez examiner attentivement sa structure réelle. Premièrement, ZFS combine les niveaux traditionnels de gestion des volumes et le système de fichiers. Deuxièmement, il utilise un mécanisme de copie transactionnelle lors de l'écriture. Ces caractéristiques signifient que le système est structurellement très différent des systèmes de fichiers ordinaires et des matrices RAID. Le premier ensemble de blocs de construction de base à comprendre: un pool de stockage (zpool), un périphérique virtuel (vdev) et un périphérique réel (périphérique).

zpool

Le pool de stockage zpool est la structure ZFS la plus élevée. Chaque pool contient un ou plusieurs périphériques virtuels. À leur tour, chacun d'eux contient un ou plusieurs appareils réels (appareil). Les pools virtuels sont des blocs autonomes. Un ordinateur physique peut contenir deux ou plusieurs pools distincts, mais chacun est complètement indépendant des autres. Les pools ne peuvent pas partager de périphériques virtuels.

La redondance de ZFS se situe au niveau des périphériques virtuels, mais pas au niveau des pools. Au niveau du pool, il n'y a absolument aucune redondance - si un lecteur vdev ou un vdev spécial est perdu, alors le pool entier est perdu avec lui.

Les pools de stockage modernes peuvent survivre à la perte d'un cache ou d'un journal de périphérique virtuel - bien qu'ils puissent perdre une petite quantité de données sales s'ils perdent le journal vdev lors d'une panne de courant ou d'un crash système.

Il existe une idée fausse commune selon laquelle des «bandes de données» (bandes) de ZFS sont enregistrées sur l'ensemble du pool. Ce n'est pas vrai. Zpool n'est pas du tout un RAID0 amusant, c'est plutôt un JBOD amusant avec un mécanisme de distribution modifiable complexe.

Pour la plupart, les entrées sont réparties entre les périphériques virtuels disponibles en fonction de l'espace disponible, donc théoriquement, elles seront toutes remplies en même temps. Dans les versions ultérieures de ZFS, l'utilisation actuelle (l'élimination) de vdev est prise en compte - si un périphérique virtuel est nettement plus chargé que l'autre (par exemple, en raison de la charge de lecture), il sera temporairement ignoré pour l'écriture, malgré la présence du coefficient d'espace libre le plus élevé.

Un mécanisme de détection du recyclage intégré aux méthodes modernes de distribution des enregistrements ZFS peut réduire la latence et augmenter le débit pendant les périodes de charge inhabituellement élevée - mais ce n'est pas carte blanchemélange involontaire de disques durs lents et de disques SSD rapides dans un seul pool. Une telle piscine inégale fonctionnera toujours à la vitesse de l'appareil le plus lent, c'est-à-dire comme s'il était entièrement composé de tels appareils.

vdev

Chaque pool de stockage se compose d'un ou plusieurs périphériques virtuels (périphérique virtuel, vdev). À son tour, chaque vdev comprend un ou plusieurs appareils réels. La plupart des périphériques virtuels sont utilisés pour stocker facilement des données, mais il existe plusieurs classes d'assistance vdev, notamment CACHE, LOG et SPECIAL. Chacun de ces types de vdev peut avoir l'une des cinq topologies: mono-périphérique, RAIDz1, RAIDz2, RAIDz3 ou miroir.

RAIDz1, RAIDz2 et RAIDz3 sont des variations spéciales de ce que les anciens appellent la parité double (diagonale) RAID. 1, 2 et 3 font référence au nombre de blocs de parité alloués pour chaque bande de données. Au lieu de disques séparés pour la parité, les périphériques RAIDz virtuels répartissent uniformément cette parité sur les disques. Une matrice RAIDz peut perdre autant de disques qu'elle a de blocs de parité; s'il en perd un autre, il échouera et emportera le pool de stockage avec lui.

Dans les périphériques virtuels en miroir (miroir vdev), chaque bloc est stocké sur chaque périphérique dans vdev. Bien qu'il s'agisse des miroirs double largeur les plus courants, il peut y avoir un nombre arbitraire de périphériques dans le miroir - dans les grandes installations, les triples sont souvent utilisés pour augmenter les performances de lecture et la tolérance aux pannes. Le miroir vdev peut survivre à toute panne pendant qu'au moins un périphérique dans vdev continue de fonctionner.

Les vdev uniques sont intrinsèquement dangereux. Un tel périphérique virtuel ne survivra pas à une seule défaillance - et s'il est utilisé comme stockage ou un vdev spécial, sa défaillance entraînera la destruction de l'ensemble du pool. Soyez très, très prudent ici.

Les appliances virtuelles CACHE, LOG et SPECIAL peuvent être créées à l'aide de l'une des topologies ci-dessus - mais n'oubliez pas que la perte d'une appliance virtuelle SPECIAL signifie la perte d'un pool, donc une topologie excessive est fortement recommandée.

dispositif

C'est probablement le terme le plus facile à comprendre dans ZFS - c'est littéralement un périphérique à accès aléatoire par blocs. N'oubliez pas que les périphériques virtuels sont constitués de périphériques individuels et que le pool est composé de périphériques virtuels.

Les disques - magnétiques ou à semi-conducteurs - sont les unités de blocs les plus courantes utilisées comme blocs de construction vdev. Cependant, tout périphérique avec une poignée dans / dev convient - vous pouvez donc utiliser des matrices RAID matérielles entières en tant que périphériques séparés.

Un fichier brut simple est l'un des périphériques de blocs alternatifs les plus importants à partir desquels vdev peut être construit. Pools de tests à partir de fichiers épars - Un moyen très pratique de vérifier les commandes du pool et de voir combien d'espace est disponible dans le pool ou le périphérique virtuel de cette topologie.

Vous pouvez créer un pool de test à partir de fichiers épars en quelques secondes - mais n'oubliez pas de supprimer le pool entier et ses composants plus tard.

Supposons que vous souhaitiez mettre un serveur sur huit disques et prévoyez d'utiliser des disques de 10 To (~ 9300 Gio) - mais vous ne savez pas exactement La topologie correspond le mieux à vos besoins. Dans l'exemple ci-dessus, en quelques secondes, nous construisons un pool de test à partir de fichiers épars - et nous savons maintenant que RAIDz2 vdev à partir de huit disques de 10 To fournit 50 TiB de capacité utile.

Une autre classe spéciale d'appareils est SPARE (rechange). Les périphériques remplaçables à chaud, contrairement aux périphériques conventionnels, appartiennent à l'ensemble du pool, pas à un seul périphérique virtuel. Si certains vdev du pool échouent et qu'un périphérique de rechange est connecté au pool et accessible, il rejoindra automatiquement le vdev affecté.

Après la connexion au vdev affecté, le périphérique de rechange commence à recevoir des copies ou la reconstruction des données qui devraient se trouver sur le périphérique manquant. Dans le RAID traditionnel, cela s'appelle la reconstruction, tandis que dans ZFS, il est appelé «resilvering».

Il est important de noter que les appareils de remplacement ne remplacent pas définitivement les appareils défectueux. Il ne s'agit que d'un remplacement temporaire pour réduire le temps pendant lequel une dégradation de vdev est observée. Une fois que l'administrateur a remplacé le périphérique vdev défectueux, la redondance est restaurée sur ce périphérique permanent et SPARE se déconnecte de vdev et retourne au travail en tant que pièce de rechange pour l'ensemble du pool.

Ensembles de données, blocs et secteurs

Le prochain ensemble de blocs de construction que vous devez comprendre lors de notre voyage à travers ZFS n'est pas tant le matériel, mais la façon dont les données sont organisées et stockées. Nous sautons plusieurs niveaux ici - comme le métaslab - afin de ne pas empiler les détails tout en maintenant une compréhension de la structure globale.

Base de données

Lorsque nous créons un ensemble de données pour la première fois, il affiche tout l'espace de pool disponible. Ensuite, nous définissons le quota - et modifions le point de montage. La magie!

Zvol n'est pour la plupart qu'un ensemble de données, dépourvu de sa couche de système de fichiers, que nous remplaçons ici par un

système de fichiers ext4 tout à fait normal . L'ensemble de données ZFS est à peu près le même qu'un système de fichiers monté standard. Comme un système de fichiers classique, il semble à première vue être «juste un autre dossier». Mais aussi, comme les systèmes de fichiers montés conventionnels, chaque jeu de données ZFS a son propre ensemble de propriétés de base.

Tout d'abord, un ensemble de données peut avoir un quota attribué. S'il est installézfs set quota=100G poolname/datasetname, vous ne pouvez pas écrire dans le dossier monté/poolname/datasetnameplus de 100 Gio.

Vous remarquez la présence - et l'absence - de barres obliques au début de chaque ligne? Chaque ensemble de données a sa propre place à la fois dans la hiérarchie ZFS et dans la hiérarchie de montage système. Il n'y a pas de barre oblique dans la hiérarchie ZFS - vous commencez avec le nom du pool, puis le chemin d'un ensemble de données au suivant. Par exemple, pool/parent/childpour un ensemble de données nommé childsous l'ensemble parentde données parent dans un pool avec un nom de création pool.

Par défaut, le point de montage de l'ensemble de données sera équivalent à son nom dans la hiérarchie ZFS, avec une barre oblique au début - le pool avec le nom est poolmonté en tant que /pool, l'ensemble de données est parentmonté dans /pool/parent, et l' ensemble de données enfant est monté childdans /pool/parent/child. Cependant, le point de montage système de l'ensemble de données peut être modifié.

Si nous indiquonszfs set mountpoint=/lol pool/parent/child, puis l'ensemble de données est pool/parent/childmonté dans le système en tant que /lol.

En plus des ensembles de données, nous devons mentionner les volumes (zvols). Un volume est à peu près similaire à un ensemble de données, sauf qu'il n'a en fait pas de système de fichiers - c'est juste un périphérique bloc. Vous pouvez, par exemple, créer zvolavec un nom mypool/myzvol, puis le formater avec le système de fichiers ext4, puis monter ce système de fichiers - vous avez maintenant le système de fichiers ext4, mais avec la prise en charge de toutes les fonctionnalités de sécurité ZFS! Cela peut sembler idiot sur un ordinateur, mais cela a beaucoup plus de sens en tant que backend lors de l'exportation d'un périphérique iSCSI.

Blocs

Un fichier est représenté par un ou plusieurs blocs. Chaque bloc est stocké sur un appareil virtuel. La taille du bloc est généralement égale au paramètre recordsize , mais peut être réduite à 2 ^ ashift s'il contient des métadonnées ou un petit fichier.

Nous ne plaisantons vraiment pas sur les énormes dommages aux performances si vous installez trop petit ashift

Dans le pool ZFS, toutes les données, y compris les métadonnées, sont stockées dans des blocs. La taille de bloc maximale pour chaque ensemble de données est définie dans la propriétérecordsize(taille d'enregistrement). La taille de l'enregistrement peut varier, mais cela ne changera pas la taille ou l'emplacement des blocs qui ont déjà été écrits dans l'ensemble de données - cela ne fonctionne que pour les nouveaux blocs au fur et à mesure qu'ils sont écrits.

Sauf indication contraire, la taille d'enregistrement actuelle est de 128 Ko par défaut. C'est une sorte de compromis difficile dans lequel les performances ne seront pas idéales, mais pas terribles dans la plupart des cas. Recordsizepeut être réglé sur n'importe quelle valeur de 4K à 1M (avec des paramètres supplémentaires, recordsizevous pouvez définir encore plus, mais c'est rarement une bonne idée).

Tout bloc fait référence aux données d'un seul fichier - vous ne pouvez pas compresser deux fichiers différents en un seul bloc. Chaque fichier se compose d'un ou plusieurs blocs, selon la taille. Si la taille du fichier est inférieure à la taille de l'enregistrement, elle sera enregistrée dans un bloc plus petit - par exemple, un bloc avec un fichier de 2 Ko n'occupera qu'un seul secteur de 4 Ko sur le disque.

Si le fichier est suffisamment volumineux et nécessite plusieurs blocs, tous les enregistrements avec ce fichier auront une taillerecordsize - y compris le dernier enregistrement, dont la partie principale peut s'avérer être de l' espace inutilisé .

Les volumes Zvol n'ont pas de propriété recordsize - ils ont plutôt une propriété équivalente volblocksize.

Les secteurs

Le dernier élément de construction le plus fondamental est le secteur. Il s'agit de la plus petite unité physique pouvant être écrite ou lue sur l'unité de base. Pendant plusieurs décennies, la plupart des disques ont utilisé des secteurs de 512 octets. Récemment, la plupart des disques sont configurés pour 4 secteurs KiB, et dans certains - en particulier les SSD - 8 secteurs KiB ou même plus.

ZFS possède une propriété qui vous permet de définir manuellement la taille du secteur. Ceci est une propriété ashift. Il est quelque peu déroutant que ashift soit une puissance de deux. Par exemple, cela ashift=9signifie une taille de secteur de 2 ^ 9, ou 512 octets.

ZFS demande au système d'exploitation des informations détaillées sur chaque périphérique de bloc lorsqu'il est ajouté au nouveau vdev et théoriquement définit automatiquement ashift correctement sur la base de ces informations. Malheureusement, de nombreux disques mentent sur leur taille de secteur afin de maintenir la compatibilité avec Windows XP (qui n'a pas pu comprendre les disques avec d'autres tailles de secteur).

Cela signifie que l'administrateur ZFS est fortement conseillé de connaître la taille réelle du secteur de leurs appareils et d'installer manuellementashift. Si un décalage trop petit est défini, le nombre d'opérations de lecture / écriture augmente astronomiquement. Donc, écrire des «secteurs» de 512 octets dans le vrai secteur de 4 Ko signifie écrire le premier «secteur», puis lire le secteur de 4 Ko, le changer avec le deuxième «secteur» de 512 octets, le réécrire dans le nouveau secteur de 4 Ko, etc. pour chaque entrée.

Dans le monde réel, une telle pénalité bat les ashift=13SSD Samsung EVO, pour lesquels elle doit agir , mais ces SSD reposent sur la taille de leur secteur, et par conséquent, elle est définie par défaut ashift=9. Si un administrateur système expérimenté ne modifie pas ce paramètre, ce SSD est plus lent qu'un disque dur magnétique classique.

A titre de comparaison, pour une taille trop grandeashiftil n'y a pratiquement pas de pénalité. Il n'y a pas de réelle diminution de la productivité et l'augmentation de l'espace inutilisé est infiniment petite (ou égale à zéro avec la compression activée). Par conséquent, nous recommandons fortement que même les disques qui utilisent réellement des secteurs de 512 octets soient installés ashift=12ou même ashift=13de regarder l'avenir avec confiance.

La propriété est ashiftdéfinie pour chaque périphérique virtuel vdev, et non pour le pool , comme beaucoup le pensent par erreur - et ne change pas après l'installation. Si vous avez accidentellement renversé ashiftlors de l'ajout d'un nouveau vdev à la piscine, vous avez irrémédiablement contaminé cette piscine avec un appareil à faible performance et, en règle générale, il n'y a pas d'autre moyen que de détruire la piscine et de tout recommencer. Même la suppression de vdev ne vous sauvera pas d'une configuration casséeashift!

— ,

, , « » « »,

, — , ,

La copie sur écriture (CoW) est le fondement fondamental de ce qui rend ZFS si génial. Le concept de base est simple - si vous demandez au système de fichiers traditionnel de modifier le fichier, il fera exactement ce que vous avez demandé. Si vous demandez au système de fichiers avec copie pendant l'enregistrement de faire de même, il vous répondra «bien» - mais cela vous ment.

Au lieu de cela, le système de fichiers copie-écriture écrit la nouvelle version du bloc modifié, puis met à jour les métadonnées du fichier pour rompre le lien avec l'ancien bloc et associer le nouveau bloc que vous venez d'écrire.

Déconnecter l'ancienne unité et relier la nouvelle se fait en une seule opération, donc elle ne peut pas être interrompue - si vous réinitialisez l'alimentation après cela, vous avez une nouvelle version du fichier, et si vous réinitialisez l'alimentation plus tôt, alors vous avez l'ancienne version. Dans tous les cas, il n'y aura pas de conflit dans le système de fichiers.

La copie lors de l'écriture dans ZFS s'effectue non seulement au niveau du système de fichiers, mais également au niveau de la gestion des disques. Cela signifie que ZFS n'est pas soumis à un espace dans l'enregistrement (un trou dans le RAID ) - un phénomène lorsque la bande n'a réussi qu'à enregistrer partiellement avant que le système ne plante, avec la baie endommagée après un redémarrage. Ici, la bande est atomique, vdev est toujours cohérent et Bob est votre oncle .

ZIL: Journal d'intention ZFS

ZFS — , ZIL,

, ZIL, .

SLOG, LOG-, — — , , — vdev, ZIL

ZIL — ZIL SLOG,

Il existe deux catégories principales d'opérations d'écriture: synchrones (sync) et asynchrones (async). Pour la plupart des charges de travail, la grande majorité des opérations d'écriture sont asynchrones - le système de fichiers vous permet de les agréger et de les livrer par lots, réduisant la fragmentation et augmentant considérablement le débit.

Les enregistrements synchrones sont une tout autre affaire. Lorsqu'une application demande une écriture synchrone, elle indique au système de fichiers: "Vous devez valider ceci dans la mémoire non volatile dès maintenant , et d'ici là, je ne peux rien faire de plus." Par conséquent, les enregistrements synchrones doivent être immédiatement validés sur le disque - et si cela augmente la fragmentation ou réduit la bande passante, qu'il en soit ainsi.

ZFS traite les enregistrements synchrones différemment des systèmes de fichiers standard - au lieu de les télécharger immédiatement dans un stockage normal, ZFS les enregistre dans une zone de stockage spéciale appelée journal d'intention ZFS - Journal d'intention ZFS ou ZIL. L'astuce est que ces enregistrements restent également en mémoire, étant agrégés avec des demandes d'écriture asynchrones régulières, pour être ensuite transférés dans le stockage en tant que TXG parfaitement normaux (groupes de transactions, groupes de transactions).

En fonctionnement normal, le ZIL est enregistré et jamais lu à nouveau. Lorsque, après quelques instants, les enregistrements de ZIL sont fixés dans le stockage principal dans le TXG ordinaire de la RAM, ils sont déconnectés de ZIL. La seule chose quand quelque chose est lu depuis ZIL est lors de l'importation du pool.

Si ZFS se bloque - le système d'exploitation se bloque ou des pannes de courant - lorsqu'il y a des données dans ZIL, ces données seront lues lors de la prochaine importation du pool (par exemple, lorsque le système d'urgence redémarre). Tout ce qui se trouve dans le ZIL sera lu, combiné en groupes TXG, engagé dans le stockage principal, puis déconnecté du ZIL pendant le processus d'importation.

L'une des classes d'assistance vdev est appelée LOG ou SLOG, le périphérique LOG secondaire. Il a une tâche - fournir au pool un périphérique vdev séparé et, de préférence beaucoup plus rapide, avec une résistance à l'écriture très élevée, pour stocker ZIL, au lieu de stocker ZIL dans le stockage vdev principal. ZIL lui-même se comporte de la même manière quel que soit l'emplacement de stockage, mais si vdev avec LOG a des performances d'écriture très élevées, les écritures synchrones seront plus rapides.

L'ajout de vdev avec LOG au pool ne peut pas améliorer les performances d'écriture asynchrone - même si vous forcez toutes les écritures dans ZIL à l'aide zfs set sync=always, elles seront toujours liées au référentiel principal dans TXG de la même manière et au même rythme que sans journal. La seule amélioration directe des performances est le retard de l'enregistrement synchrone (car une vitesse d'enregistrement plus élevée accélère les opérations sync).

Cependant, dans un environnement qui nécessite déjà un grand nombre d'écritures synchrones, vdev LOG peut indirectement accélérer les écritures asynchrones et les lectures non mises en cache. Le téléchargement d'enregistrements ZIL vers un journal vdev séparé signifie moins de concurrence pour les IOPS dans le stockage principal, ce qui améliore dans une certaine mesure les performances de toutes les opérations de lecture et d'écriture.

Instantanés

Le mécanisme de copie en écriture est également une base essentielle pour les instantanés ZFS atomiques et la réplication asynchrone incrémentielle. Le système de fichiers actif a une arborescence de pointeurs qui marque tous les enregistrements avec les données actuelles - lorsque vous prenez un instantané, vous faites simplement une copie de cette arborescence de pointeurs.

Lorsqu'un enregistrement est écrasé dans le système de fichiers actif, ZFS écrit d'abord la nouvelle version du bloc dans l'espace inutilisé. Il détache ensuite l'ancienne version du bloc du système de fichiers actuel. Mais si un instantané fait référence à l'ancien bloc, il reste inchangé. L'ancien bloc ne sera pas restauré en tant qu'espace libre jusqu'à ce que tous les instantanés liés à ce bloc soient détruits!

La réplication

Steam 2015 158 126 927 . rsync — ZFS « » 750% .

40- Windows 7 — . ZFS 289 , rsync — «» 161 , , rsync --inplace.

, rsync . 1,9 — , ZFS 1148 , rsync, rsync --inplace

Une fois que vous comprenez le fonctionnement des instantanés, il est facile de saisir l'essence de la réplication. Puisqu'un instantané n'est qu'un arbre de pointeurs vers des enregistrements, il s'ensuit que si nous faisons un zfs sendinstantané, nous envoyons cet arbre et tous les enregistrements qui lui sont associés. Lorsque nous passons ce zfs senddans zfs receivel'objet cible, il écrit deux le contenu réel du bloc et l'arbre des pointeurs qui font référence à des blocs à l'ensemble de données cible.

Tout devient encore plus intéressant dans la seconde zfs send. Nous avons maintenant deux systèmes, chacun contenant poolname/datasetname@1, et vous prenez un nouveau cliché poolname/datasetname@2. Par conséquent, dans le pool source que vous avez datasetname@1et datasetname@2, et dans le pool cible jusqu'à présent, seul le premier instantané datasetname@1.

Puisque nous avons un instantané commun entre la source et la cibledatasetname@1, nous pouvons faire incrémentiel zfs send par-dessus. Lorsque nous disons au système zfs send -i poolname/datasetname@1 poolname/datasetname@2, il compare deux arbres de pointeurs. Tous les pointeurs qui n'existent que dans @2, évidemment, se réfèrent à de nouveaux blocs - nous avons donc besoin du contenu de ces blocs.

Sur un système distant, le traitement incrémentiel est sendtout aussi simple. Tout d'abord, nous enregistrons toutes les nouvelles entrées incluses dans le flux send, puis ajoutons des pointeurs à ces blocs. Voila, dans notre @2nouveau système!

La réplication incrémentielle asynchrone ZFS est une énorme amélioration par rapport aux méthodes non instantanées antérieures comme rsync. Dans les deux cas, seules les données modifiées sont transmises - mais rsync doit d'abord liredu disque toutes les données des deux côtés pour vérifier le montant et le comparer. En revanche, la réplication ZFS ne lit rien, sauf les arborescences de pointeurs - et les blocs qui ne sont pas représentés dans l'instantané général.

Compression en ligne

Le mécanisme de copie sur écriture simplifie également le système de compression intégré. Dans un système de fichiers traditionnel, la compression est problématique - l'ancienne version et la nouvelle version des données modifiées se trouvent dans le même espace.

Si vous considérez un morceau de données au milieu d'un fichier qui commence sa vie comme un mégaoctet de zéros à partir de 0x00000000 et ainsi de suite - il est très facile de le compresser en un secteur sur le disque. Mais que se passe-t-il si nous remplaçons ce mégaoctet de zéros par un mégaoctet de données incompressibles comme le JPEG ou le bruit pseudo-aléatoire? Du coup, ce mégaoctet de données ne nécessitera pas un, mais 256 secteurs de 4 Ko, et à cet endroit sur le disque un seul secteur est réservé.

ZFS n'a pas un tel problème, car les enregistrements modifiés sont toujours écrits dans l'espace inutilisé - le bloc d'origine n'occupe qu'un seul secteur de 4 Ko, et un nouvel enregistrement prendra 256, mais ce n'est pas un problème - un fragment récemment modifié du «milieu» du fichier serait écrit dans l'espace inutilisé indépendamment du fait que sa taille ait changé ou non, donc pour ZFS, c'est une situation normale.

La compression ZFS intégrée est désactivée par défaut, et le système propose des algorithmes de plug-in - maintenant parmi eux sont LZ4, gzip (1-9), LZJB et ZLE.

LZ4 est un algorithme de streaming qui offre une compression et une décompression extrêmement rapides et des gains de performances pour la plupart des cas d'utilisation - même sur des processeurs assez lents.
GZIP — , Unix-. 1-9, CPU 9. ( ) , c CPU — , .
LZJB — ZFS. , LZ4 .
ZLE - encodage de niveau zéro, encodage de niveau zéro. Il ne touche pas du tout aux données normales, mais compresse de grandes séquences de zéros. Utile pour les ensembles de données complètement incompressibles (par exemple, JPEG, MP4 ou d'autres formats déjà compressés), car il ignore les données incompressibles, mais compresse l'espace inutilisé dans les enregistrements résultants.

Nous recommandons la compression LZ4 pour presque tous les cas d'utilisation; La pénalité de performances pour rencontrer des données incompressibles est très faible et le gain de performances pour les données typiques est significatif. Copier une image de machine virtuelle pour une nouvelle installation du système d'exploitation Windows (système d'exploitation fraîchement installé, aucune donnée à l'intérieur pour l'instant) avec compression=lz4passé 27% plus rapidement qu'avec compression=none, dans ce test de 2015 .

ARC - cache de remplacement adaptatif

ZFS est le seul système de fichiers moderne à notre connaissance qui utilise son propre mécanisme de mise en cache de lecture et ne s'appuie pas sur le cache de pages du système d'exploitation pour stocker des copies des blocs récemment lus dans la RAM.

Bien que son propre cache ne soit pas sans problèmes - ZFS ne peut pas répondre aux nouvelles demandes d'allocation de mémoire aussi rapidement que le noyau, donc un nouvel appel d' malloc()allocation de mémoire peut échouer s'il a besoin de RAM actuellement occupée par ARC. Mais il y a de bonnes raisons d'utiliser votre propre cache, du moins pour l'instant.

Tous les systèmes d'exploitation modernes bien connus, y compris MacOS, Windows, Linux et BSD, utilisent l'algorithme LRU (le moins récemment utilisé) pour implémenter le cache de pages. Il s'agit d'un algorithme primitif qui soulève le bloc mis en cache «en haut de la file d'attente» après chaque lecture et pousse les blocs «en file d'attente» au besoin pour ajouter de nouveaux échecs de cache (blocs qui auraient dû être lus à partir du disque, pas à partir du cache).

Habituellement, l'algorithme fonctionne bien, mais sur les systèmes avec de grands ensembles de données de travail, LRU mène facilement à la destruction - évincant les blocs fréquemment nécessaires pour faire de la place pour les blocs qui ne seront plus jamais lus dans le cache.

ARC - un algorithme beaucoup moins naïf, qui peut être considéré comme un cache "pondéré". Après chaque lecture du bloc mis en cache, il devient un peu «plus lourd» et il devient plus difficile à évincer - et même après avoir évincé le bloc est suivi pendant une certaine période de temps. Un bloc qui a été éliminé mais qui doit ensuite être relu dans le cache deviendra également «plus lourd».

Le résultat final de tout cela est un cache avec un taux de réussite beaucoup plus élevé - le rapport entre les succès dans le cache (lus dans le cache) et les ratés (lus sur le disque). Il s'agit de statistiques extrêmement importantes - non seulement le cache atteint lui-même des ordres de grandeur de service plus rapides, mais les échecs de cache peuvent également être traités plus rapidement, car plus il y a d'occurrences de cache, moins il y a de demandes de disque simultanées et moins le délai pour les autres manquants qui doivent être traités avec conduire.

Conclusion

Après avoir étudié la sémantique de base de ZFS - comment fonctionne la copie pendant l'écriture, ainsi que les relations entre les pools de stockage, les périphériques virtuels, les blocs, les secteurs et les fichiers - nous sommes prêts à discuter des performances réelles avec des nombres réels.

Dans la partie suivante, nous examinerons les performances réelles des pools avec vdev en miroir et RAIDz, en comparaison les uns avec les autres, ainsi qu'en comparaison avec les topologies RAID traditionnelles du noyau Linux, que nous avons examinées précédemment .

Au début, nous voulions considérer uniquement les bases - les topologies ZFS elles-mêmes - mais après cela, nous serons prêts à parler d'un réglage et d'un réglage ZFS plus avancés, y compris l'utilisation de types de vdev auxiliaires tels que L2ARC, SLOG et allocation spéciale.

Bases de ZFS: stockage et performances