ZFS sous Linux
Contenu
- Matériel
- Installation en tant que système de fichiers racine
- Considérations relatives au niveau RAID ZFS
- Chargeur de démarrage
- Administration ZFS
- Activer la notification par e-mail
- Limiter l'utilisation de la mémoire ZFS
- ÉCHANGE sur ZFS
- Ensembles de données ZFS cryptés
- Compression dans ZFS
- Dispositif spécial ZFS
- Fonctionnalités du pool ZFS
ZFS est un système de fichiers combiné et un gestionnaire de volumes logiques conçu par Sun Microsystems. À partir de Proxmox VE 3.4, le port de noyau Linux natif du système de fichiers ZFS est présenté en tant que système de fichiers facultatif et également en tant que sélection supplémentaire pour le système de fichiers racine. Il n'est pas nécessaire de compiler manuellement les modules ZFS - tous les packages sont inclus.
En utilisant ZFS, il est possible d'obtenir un maximum de fonctionnalités d'entreprise avec du matériel à petit budget, mais aussi des systèmes hautes performances en tirant parti de la mise en cache SSD ou même des configurations SSD uniquement. ZFS peut remplacer les cartes RAID matérielles coûteuses par une charge CPU et mémoire modérée combinée à une gestion facile.
-
Configuration et gestion faciles avec l'interface graphique et l'interface de ligne de commande Proxmox VE.
-
Fiable
-
Protection contre la corruption des données
-
Compression des données au niveau du système de fichiers
-
Instantanés
-
Clonage de copie sur écriture
-
Différents niveaux de raid : RAID0, RAID1, RAID10, RAIDZ-1, RAIDZ-2 et RAIDZ-3
-
Peut utiliser SSD pour le cache
-
Auto-guérison
-
Contrôle continu de l'intégrité
-
Conçu pour des capacités de stockage élevées
-
Réplication asynchrone sur le réseau
-
Open source
-
Chiffrement
-
…
Matériel
ZFS dépend fortement de la mémoire, vous avez donc besoin d'au moins 8 Go pour démarrer. En pratique, utilisez autant que possible pour votre matériel/budget. Pour éviter la corruption des données, nous recommandons l'utilisation d'une RAM ECC de haute qualité.
Si vous utilisez un cache dédié et/ou un disque de journalisation, vous devez utiliser un SSD de classe entreprise (par exemple Intel SSD DC S3700 Series). Cela peut augmenter considérablement les performances globales.
N'utilisez pas ZFS sur un contrôleur RAID matériel qui a sa propre gestion de cache. ZFS doit communiquer directement avec les disques. Un adaptateur HBA ou quelque chose comme un contrôleur LSI flashé en mode "IT" est plus approprié. |
Si vous expérimentez une installation de Proxmox VE à l'intérieur d'une VM (Nested Virtualization), n'utilisez pas virtio pour les disques de cette VM, car ils ne sont pas pris en charge par ZFS. Utilisez plutôt IDE ou SCSI (fonctionne également avec le type de contrôleur virtio SCSI).
Installation en tant que système de fichiers racine
Lorsque vous effectuez l'installation à l'aide du programme d'installation de Proxmox VE, vous pouvez choisir ZFS pour le système de fichiers racine. Vous devez sélectionner le type de RAID au moment de l'installation :
RAID0 |
Aussi appelé « rayage ». La capacité d'un tel volume est la somme des capacités de tous les disques. Mais RAID0 n'ajoute aucune redondance, donc la panne d'un seul disque rend le volume inutilisable. |
RAID1 |
Aussi appelé "miroir". Les données sont écrites de manière identique sur tous les disques. Ce mode nécessite au moins 2 disques de même taille. La capacité résultante est celle d'un seul disque. |
RAID10 |
Une combinaison de RAID0 et RAID1. Nécessite au moins 4 disques. |
RAIDZ-1 |
Une variation sur RAID-5, parité unique. Nécessite au moins 3 disques. |
RAIDZ-2 |
Une variation sur RAID-5, double parité. Nécessite au moins 4 disques. |
RAIDZ-3 |
Une variation sur RAID-5, triple parité. Nécessite au moins 5 disques. |
Le programme d'installation partitionne automatiquement les disques, crée un pool ZFS appelé rpool et installe le système de fichiers racine sur le sous- volume ZFS rpool/ROOT/pve-1 .
Un autre sous- volume appelé rpool/data est créé pour stocker les images de VM. Afin de l'utiliser avec les outils Proxmox VE, le programme d'installation crée l'entrée de configuration suivante dans /etc/pve/storage.cfg :
zfspool : local-zfs pool rpool/données clairsemé images de contenu, répertoire racine
Après l'installation, vous pouvez afficher l'état de votre pool ZFS à l'aide de la commande zpool :
# état de zpool piscine: rpool état : EN LIGNE analyse : aucune demandée configuration : NOM ETAT LIRE ECRIRE CKSUM rpool EN LIGNE 0 0 0 miroir-0 EN LIGNE 0 0 0 sda2 EN LIGNE 0 0 0 sdb2 EN LIGNE 0 0 0 miroir-1 EN LIGNE 0 0 0 sdc EN LIGNE 0 0 0 sdd EN LIGNE 0 0 0 erreurs : aucune erreur de données connue
La commande zfs est utilisée pour configurer et gérer vos systèmes de fichiers ZFS. La commande suivante répertorie tous les systèmes de fichiers après l'installation :
# liste zfs NOM UTILISÉ DISPONIBILITÉ RÉFÉRER POINT DE MONTAGE rpool 4.94G 7.68T 96K /rpool rpool/ROOT 702M 7.68T 96K /rpool/ROOT rpool/ROOT/pve-1 702M 7.68T 702M / rpool/données 96K 7.68T 96K /rpool/données rpool/swap 4.25G 7.69T 64K -
Considérations relatives au niveau RAID ZFS
Il y a quelques facteurs à prendre en considération lors du choix de la disposition d'un pool ZFS. Le bloc de construction de base d'un pool ZFS est le périphérique virtuel, ou vdev . Tous les vdevs d'un pool sont utilisés de manière égale et les données sont réparties entre eux (RAID0). Consultez la page de manuel zpool(8) pour plus de détails sur vdevs.
Performance
Chaque type de vdev a des comportements de performances différents. Les deux paramètres d'intérêt sont les IOPS (opérations d'entrée/sortie par seconde) et la bande passante avec laquelle les données peuvent être écrites ou lues.
Un miroir vdev (RAID1) se comportera approximativement comme un seul disque en ce qui concerne les deux paramètres lors de l'écriture des données. Lors de la lecture des données, il se comportera comme le nombre de disques dans le miroir.
Une situation courante est d'avoir 4 disques. Lors de sa configuration en tant que 2 vdevs miroir (RAID10), le pool aura les caractéristiques d'écriture de deux disques uniques en ce qui concerne les IOPS et la bande passante. Pour les opérations de lecture, il ressemblera à 4 disques simples.
Un RAIDZ de n'importe quel niveau de redondance se comportera approximativement comme un seul disque en ce qui concerne les IOPS avec beaucoup de bande passante. La quantité de bande passante dépend de la taille du vdev RAIDZ et du niveau de redondance.
Pour exécuter des machines virtuelles, IOPS est la métrique la plus importante dans la plupart des situations.
Taille, utilisation de l'espace et redondance
Alors qu'un pool composé de vdevs miroir aura les meilleures caractéristiques de performances, l'espace utilisable sera de 50 % des disques disponibles. Moins si un miroir vdev se compose de plus de 2 disques, par exemple dans un miroir 3-way. Au moins un disque sain par miroir est nécessaire pour que le pool reste fonctionnel.
L'espace utilisable d'un vdev de type RAIDZ de N disques est d'environ NP, P étant le niveau RAIDZ. Le niveau RAIDZ indique combien de disques arbitraires peuvent tomber en panne sans perte de données. Un cas particulier est un pool de 4 disques avec RAIDZ2. Dans cette situation, il est généralement préférable d'utiliser 2 vdev miroir pour de meilleures performances car l'espace utilisable sera le même.
Un autre facteur important lors de l'utilisation de n'importe quel niveau RAIDZ est le comportement des ensembles de données ZVOL, qui sont utilisés pour les disques VM. Pour chaque bloc de données, le pool a besoin de données de parité qui correspondent au moins à la taille de bloc minimale définie par la valeur de décalage du pool. Avec un décalage de 12, la taille du bloc de la piscine est de 4k. La taille de bloc par défaut pour un ZVOL est de 8k. Par conséquent, dans un RAIDZ2, chaque bloc de 8k écrit entraînera l'écriture de deux blocs de parité supplémentaires de 4k, 8k + 4k + 4k = 16k. Il s'agit bien sûr d'une approche simplifiée et la situation réelle sera légèrement différente avec les métadonnées, la compression et autres non pris en compte dans cet exemple.
Ce comportement peut être observé lors de la vérification des propriétés suivantes du ZVOL :
-
volize
-
refreservation (si le pool n'est pas thin provisioned)
-
utilisé (si le pool est provisionné de manière dynamique et sans instantanés présents)
# zfs get volssize,refreservation,used <pool>/vm-<vmid>-disk-X
volsize est la taille du disque telle qu'elle est présentée à la machine virtuelle, tandis que la refreservation affiche l'espace réservé sur le pool qui inclut l'espace attendu nécessaire pour les données de parité. Si le pool est provisionné de manière dynamique , la refreservation sera définie sur 0. Une autre façon d'observer le comportement consiste à comparer l'espace disque utilisé dans la machine virtuelle et lapropriété utilisée . Sachez que les instantanés fausseront la valeur.
Il existe quelques options pour contrer l'utilisation accrue de l'espace :
-
Augmentez la taille du bloc de volume pour améliorer le rapport données/parité
-
Utiliser des vdevs miroir au lieu de RAIDZ
-
Utilisez ashift=9 (taille de bloc de 512 octets)
La propriété volblocksize ne peut être définie que lors de la création d'un ZVOL. La valeur par défaut peut être modifiée dans la configuration de stockage. Lors de cette opération, l'invité doit être réglé en conséquence et, selon le cas d'utilisation, le problème d'amplification d'écriture s'il vient d'être déplacé de la couche ZFS vers l'invité.
L'utilisation de ashift=9 lors de la création du pool peut entraîner de mauvaises performances, selon les disques sous-jacents, et ne peut pas être modifiée ultérieurement.
Les vdev miroirs (RAID1, RAID10) ont un comportement favorable pour les charges de travail des machines virtuelles. Utilisez-les, sauf si votre environnement a des besoins et des caractéristiques spécifiques où les caractéristiques de performances RAIDZ sont acceptables.
Chargeur de démarrage
Proxmox VE utilise proxmox-boot-tool pour gérer la configuration du chargeur de démarrage. Voir le chapitre sur les chargeurs de démarrage hôte Proxmox VE pour plus de détails.
Administration ZFS
Cette section vous donne quelques exemples d'utilisation de tâches courantes. ZFS lui-même est vraiment puissant et offre de nombreuses options. Les commandes principales pour gérer ZFS sont zfs et zpool . Les deux commandes sont accompagnées d'excellentes pages de manuel, qui peuvent être lues avec :
# homme zpool # homme zfs
Créer un nouveau zpool
Pour créer un nouveau pool, au moins un disque est nécessaire. L' ashift doit avoir la même taille de secteur (2 puissances d' ashift ) ou plus que le disque sous-jacent.
# zpool create -f -o ashift=12 <pool> <device>
Pour activer la compression (voir section Compression dans ZFS ) :
# zfs set compression=lz4 <pool>
Créer un nouveau pool avec RAID-0
Au moins 1 disque
# zpool create -f -o ashift=12 <pool> <device1> <device2>
Créer un nouveau pool avec RAID-1
Au moins 2 disques
# zpool create -f -o ashift=12 <pool> mirror <device1> <device2>
Créer un nouveau pool avec RAID-10
Au moins 4 disques
# zpool create -f -o ashift=12 <pool> mirror <device1> <device2> mirror <device3> <device4>
Créer un nouveau pool avec RAIDZ-1
Au moins 3 disques
# zpool create -f -o ashift=12 <pool> raidz1 <device1> <device2> <device3>
Créer un nouveau pool avec RAIDZ-2
Au moins 4 disques
# zpool create -f -o ashift=12 <pool> raidz2 <device1> <device2> <device3> <device4>
Créer un nouveau pool avec cache (L2ARC)
Il est possible d'utiliser une partition de lecteur de cache dédiée pour augmenter les performances (utiliser SSD).
En tant que <device>, il est possible d'utiliser plus de périphériques, comme indiqué dans "Créer un nouveau pool avec RAID*".
# zpool create -f -o ashift=12 <pool> <device> cache <cache_device>
Créer un nouveau pool avec log (ZIL)
Il est possible d'utiliser une partition de lecteur de cache dédiée pour augmenter les performances (SSD).
En tant que <device>, il est possible d'utiliser plus de périphériques, comme indiqué dans "Créer un nouveau pool avec RAID*".
# zpool create -f -o ashift=12 <pool> <device> log <log_device>
Ajouter un cache et un journal à un pool existant
Si vous avez un pool sans cache ni log. Commencez par partitionner le SSD en 2 partitions avec parted ou gdisk
Utilisez toujours les tables de partition GPT. |
La taille maximale d'un périphérique de journalisation doit être environ la moitié de la taille de la mémoire physique, elle est donc généralement assez petite. Le reste du SSD peut être utilisé comme cache.
# zpool add -f <pool> log <device-part1> cache <device-part2>
Changer un appareil défaillant
# zpool replace -f <pool> <ancien périphérique> <nouveau périphérique>
Changer un périphérique amorçable défaillant
Selon la façon dont Proxmox VE a été installé, il utilise soit proxmox-boot-tool [ 1 ] ou plain grub comme bootloader (voir Host Bootloader ). Vous pouvez vérifier en exécutant :
# statut proxmox-boot-tool
Les premières étapes de copie de la table de partition, de réémission des GUID et de remplacement de la partition ZFS sont les mêmes. Pour rendre le système amorçable à partir du nouveau disque, différentes étapes sont nécessaires en fonction du chargeur de démarrage utilisé.
# sgdisk <périphérique amorçable sain> -R <nouveau périphérique> # sgdisk -G <nouveau périphérique> # zpool replace -f <pool> <ancienne partition zfs> <nouvelle partition zfs>
Utilisez la commande zpool status -v pour surveiller la progression du processus de réargenture du nouveau disque. |
# format proxmox-boot-tool <ESP du nouveau disque> # proxmox-boot-tool init <ESP du nouveau disque>
ESP signifie EFI System Partition, qui est configuré en tant que partition n°2 sur les disques de démarrage configurés par le programme d'installation de Proxmox VE depuis la version 5.4. Pour plus de détails, consultez Configuration d'une nouvelle partition à utiliser en tant qu'ESP synchronisé . |
# grub-install <nouveau disque>
Activer la notification par e-mail
ZFS est livré avec un démon d'événement, qui surveille les événements générés par le module du noyau ZFS. Le démon peut également envoyer des e-mails sur des événements ZFS tels que des erreurs de pool. Les nouveaux packages ZFS expédient le démon dans un package séparé, et vous pouvez l'installer en utilisant apt-get :
# apt-get install zfs-zed
Pour activer le démon il faut éditer /etc/zfs/zed.d/zed.rc avec votre éditeur préféré, et décommenter le paramètre ZED_EMAIL_ADDR :
ZED_EMAIL_ADDR="racine"
Veuillez noter que Proxmox VE transfère les e-mails à root à l'adresse e-mail configurée pour l'utilisateur root.
Le seul paramètre requis est ZED_EMAIL_ADDR . Tous les autres paramètres sont facultatifs. |
Limiter l'utilisation de la mémoire ZFS
ZFS utilise 50% de la mémoire hôte pour le A daptive R eplacement C ache (ARC) par défaut. L'allocation de suffisamment de mémoire pour l'ARC est cruciale pour les performances d'E/S, donc réduisez-la avec prudence. En règle générale, allouez au moins 2 Gio de base + 1 Gio/TiB de stockage . Par exemple, si vous disposez d'un pool avec 8 Tio d'espace de stockage disponible, vous devez utiliser 10 Gio de mémoire pour l'ARC.
Vous pouvez modifier la limite d'utilisation de l'ARC pour le démarrage actuel (un redémarrage réinitialise ce changement) en écrivant directement dans le paramètre du module zfs_arc_max :
echo "$[10 * 1024*1024*1024]" >/sys/module/zfs/parameters/zfs_arc_max
Pour modifier définitivement les limites ARC, ajoutez la ligne suivante à /etc/modprobe.d/zfs.conf :
options zfs zfs_arc_max=8589934592
Cet exemple de paramètre limite l'utilisation à 8 Gio ( 8 * 2 30 ).
Si la valeur zfs_arc_max souhaitée est inférieure ou égale à zfs_arc_min (qui est par défaut 1/32 de la mémoire système), zfs_arc_max sera ignoré à moins que vous ne définissiez également zfs_arc_min sur au plus zfs_arc_max - 1 . |
echo "$[8 * 1024*1024*1024 - 1]" >/sys/module/zfs/parameters/zfs_arc_min echo "$[8 * 1024*1024*1024]" >/sys/module/zfs/parameters/zfs_arc_max
Cet exemple de paramètre limite (temporairement) l'utilisation à 8 Gio ( 8 * 2 30 ) sur les systèmes avec plus de 256 Gio de mémoire totale, où le simple fait de définir zfs_arc_max seul ne fonctionnerait pas.
Si votre système de fichiers racine est ZFS, vous devez mettre à jour votre initramfs à chaque fois que cette valeur change : # update-initramfs -u Vous devez redémarrer pour activer ces modifications. |
ÉCHANGE sur ZFS
L'espace d'échange créé sur un zvol peut générer des problèmes, comme le blocage du serveur ou la génération d'une charge d'E/S élevée, souvent observée lors du démarrage d'une sauvegarde sur un stockage externe.
Nous vous recommandons fortement d'utiliser suffisamment de mémoire, de sorte que vous ne soyez normalement pas confronté à des situations de faible mémoire. Si vous avez besoin ou souhaitez ajouter du swap, il est préférable de créer une partition sur un disque physique et de l'utiliser comme périphérique de swap. Vous pouvez laisser de l'espace libre à cet effet dans les options avancées de l'installateur. De plus, vous pouvez réduire la valeur de « permutation ». Une bonne valeur pour les serveurs est 10 :
# sysctl -w vm.swappiness=10
Pour rendre le swappiness persistant, ouvrez /etc/sysctl.conf avec un éditeur de votre choix et ajoutez la ligne suivante :
vm.swappiness = 10
Valeur | Stratégie |
---|---|
vm.swappiness = 0 |
Le noyau ne permutera que pour éviter une condition de manque de mémoire |
vm.swappiness = 1 |
Quantité minimale d'échange sans le désactiver complètement. |
vm.swappiness = 10 |
Cette valeur est parfois recommandée pour améliorer les performances lorsqu'une mémoire suffisante existe dans un système. |
vm.swappiness = 60 |
La valeur par défaut. |
vm.swappiness = 100 |
Le noyau permutera agressivement. |
Ensembles de données ZFS cryptés
ZFS sur Linux version 0.8.0 a introduit la prise en charge du chiffrement natif des ensembles de données. Après une mise à niveau depuis les versions précédentes de ZFS sur Linux, la fonction de chiffrement peut être activée par pool :
# zpool get feature@encryption tank NOM PROPRIÉTÉ VALEUR SOURCE tank feature@encryption désactivé local # zpool set feature@encryption=enabled # zpool get feature@encryption tank NOM PROPRIÉTÉ VALEUR SOURCE tank feature@encryption activé local
Il n'y a actuellement aucune prise en charge du démarrage à partir de pools avec des ensembles de données chiffrés à l'aide de Grub, et seulement une prise en charge limitée pour le déverrouillage automatique des ensembles de données chiffrés au démarrage. Les anciennes versions de ZFS sans prise en charge du chiffrement ne pourront pas déchiffrer les données stockées. |
Il est recommandé soit de déverrouiller les ensembles de données de stockage manuellement après le démarrage, soit d'écrire une unité personnalisée pour transmettre le matériel de clé nécessaire au déverrouillage au démarrage à zfs load-key . |
Établissez et testez une procédure de sauvegarde avant d'activer le chiffrement des données de production. Si le matériel de clé/phrase de passe/fichier de clé associé a été perdu, l'accès aux données cryptées n'est plus possible. |
Le chiffrement doit être configuré lors de la création d'ensembles de données/zvols, et est hérité par défaut des ensembles de données enfants. Par exemple, pour créer un ensemble de données crypté tank/encrypted_data et le configurer comme stockage dans Proxmox VE, exécutez les commandes suivantes :
# zfs create -o encryption=on -o keyformat=passphrase tank/encrypted_data Saisissez la phrase secrète : Saisissez à nouveau la phrase secrète : # pvesm add zfspoolcoded_zfs -pool tank/encrypted_data
Tous les volumes/disques invités créés sur ce stockage seront chiffrés avec le matériel de clé partagée de l'ensemble de données parent.
Pour utiliser réellement le stockage, le matériel de clé associé doit être chargé et l'ensemble de données doit être monté. Cela peut être fait en une seule étape avec :
# zfs mount -l tank/encrypted_data Saisissez la phrase secrète pour « tank/encrypted_data » :
Il est également possible d'utiliser un fichier de clé (aléatoire) au lieu de demander une phrase secrète en définissant les propriétés keylocation et keyformat , soit au moment de la création, soit avec zfs change-key sur les ensembles de données existants :
# dd if=/dev/urandom of=/path/to/keyfile bs=32 count=1 # zfs change-key -o keyformat=raw -o keylocation=file:///chemin/vers/keyfile tank/encrypted_data
Lors de l'utilisation d'un fichier de clé, des précautions particulières doivent être prises pour sécuriser le fichier de clé contre tout accès non autorisé ou perte accidentelle. Sans le fichier de clé, il n'est pas possible d'accéder aux données en clair ! |
Un volume invité créé sous un ensemble de données chiffré aura sa propriété encryptionroot définie en conséquence. Le matériel de clé n'a besoin d'être chargé qu'une seule fois par racine de chiffrement pour être disponible pour tous les ensembles de données chiffrés en dessous.
Voir la encryptionroot , le cryptage , KeyLocation , keyformat et keystatus propriétés, la charge touche zfs , zfs DECHARGEMENT-clés et changement clé zfs commandes et le chiffrement section de zfs homme pour plus de détails et l' utilisation avancée.
Compression dans ZFS
Lorsque la compression est activée sur un jeu de données, ZFS essaie de compresser tous les nouveaux blocs avant de les écrire et les décompresse lors de la lecture. Les données déjà existantes ne seront pas compressées rétroactivement.
Vous pouvez activer la compression avec :
# zfs set compression=<algorithme> <ensemble de données>
Nous vous recommandons d'utiliser l' algorithme lz4 , car il ajoute très peu de temps système au processeur. D'autres algorithmes comme lzjb et gzip-N , où N est un entier compris entre 1 (le plus rapide) et 9 (le meilleur taux de compression), sont également disponibles. Selon l'algorithme et le degré de compressibilité des données, l'activation de la compression peut même augmenter les performances d'E/S.
Vous pouvez désactiver la compression à tout moment avec :
# zfs set compression=off <ensemble de données>
Encore une fois, seuls les nouveaux blocs seront affectés par ce changement.
Dispositif spécial ZFS
Depuis la version 0.8.0, ZFS prend en charge les périphériques spéciaux . Un périphérique spécial dans un pool est utilisé pour stocker des métadonnées, des tables de déduplication et éventuellement de petits blocs de fichiers.
Un périphérique spécial peut améliorer la vitesse d'un pool composé de disques durs à rotation lente avec de nombreuses modifications de métadonnées. Par exemple, les charges de travail qui impliquent la création, la mise à jour ou la suppression d'un grand nombre de fichiers bénéficieront de la présence d'un périphérique spécial . Les ensembles de données ZFS peuvent également être configurés pour stocker des petits fichiers entiers sur le périphérique spécial , ce qui peut encore améliorer les performances. Utilisez des SSD rapides pour le périphérique spécial .
La redondance du périphérique spécial doit correspondre à celle du pool, car le périphérique spécial est un point de défaillance pour l'ensemble du pool. |
L'ajout d'un appareil spécial à un pool ne peut pas être annulé ! |
# zpool create -f -o ashift=12 <pool> mirror <device1> <device2> special mirror <device3> <device4>
# zpool add <pool> miroir spécial <device1> <device2>
Les ensembles de données ZFS exposent la propriété special_small_blocks=<size> . la taille peut être 0 pour désactiver le stockage de petits blocs de fichiers sur le périphérique spécial ou une puissance de deux comprise entre 512B et 128K . Après avoir défini la propriété, de nouveaux blocs de fichiers plus petits que la taille seront alloués sur le périphérique spécial .
Si la valeur de special_small_blocks est supérieure ou égale à la recordsize (par défaut 128K ) de l'ensemble de données, toutes les données seront écrites sur le spécial appareil, alors soyez prudent! |
La définition de la propriété special_small_blocks sur un pool modifiera la valeur par défaut de cette propriété pour tous les ensembles de données ZFS enfants (par exemple, tous les conteneurs du pool opteront pour les petits blocs de fichiers).
# zfs défini special_small_blocks=4K <pool>
# zfs set special_small_blocks=4K <pool>/<filesystem>
# zfs set special_small_blocks=0 <pool>/<filesystem>
Fonctionnalités du pool ZFS
Les modifications du format sur disque dans ZFS ne sont apportées qu'entre les changements de version majeurs et sont spécifiées via les fonctionnalités . Toutes les fonctionnalités, ainsi que le mécanisme général, sont bien documentés dans la page de manuel zpool-features(5) .
Étant donné que l'activation de nouvelles fonctionnalités peut rendre un pool non importable par une ancienne version de ZFS, cela doit être fait activement par l'administrateur, en exécutant zpool upgrade sur le pool (voir la page de manuel zpool-upgrade(8) ).
À moins que vous n'ayez besoin d'utiliser l'une des nouvelles fonctionnalités, il n'y a aucun avantage à les activer.
En fait, l'activation de nouvelles fonctionnalités présente certains inconvénients :
-
Un système avec root sur ZFS, qui démarre toujours à l'aide de grub, ne pourra plus démarrer si une nouvelle fonctionnalité est active sur le rpool, en raison de l'implémentation incompatible de ZFS dans grub.
-
Le système ne pourra pas importer de pool mis à niveau lorsqu'il est démarré avec un noyau plus ancien, qui est toujours livré avec les anciens modules ZFS.
-
Le démarrage d'un ISO Proxmox VE plus ancien pour réparer un système qui ne démarre pas ne fonctionnera pas non plus.
Ne mettez pas à niveau votre rpool si votre système est toujours démarré avec grub , car cela rendra votre système non amorçable. Cela inclut les systèmes installés avant Proxmox VE 5.4 et les systèmes démarrant avec le démarrage BIOS hérité (voir comment déterminer le chargeur de démarrage ). |
# mise à niveau zpool <pool>