https://arstechnica.com/information-technology/2020/05/zfs-101-understanding-zfs-storage-and-performance/
https://unixdigest.com/articles/battle-testing-zfs-btrfs-and-mdadm-dm.html
https://openzfs.org/wiki/Newcomers
https://openzfs.github.io/openzfs-docs/Project%20and%20Community/FAQ.html
https://blog.victormendonca.com/2020/11/03/zfs-for-dummies/
https://www.reddit.com/r/zfs/
https://forum.level1techs.com/t/zfs-guide-for-starters-and-advanced-users-concepts-pool-config-tuning-troubleshooting/196035
Généralités
ZFS est une architecture qui combine des fonctionnalités de gestion de volumes, et de système de fichiers.
Recommandé de conserver au moins ~10% d’espace libre (ou 500Go, le + petit des 2 devrait être ok) dans le pool pour éviter de sérieusement dégrader les performances.
Architecture
zpool
Géré avec la commande zpool.
Le plus gros ensemble sous ZFS s’appelle un zpool. Il est constitué de 1 ou plusieurs vdevs, chaque vdev étant constitué d'1 ou plusieurs périphérique (disque physique, partition, mapper LUKS, fichier etc).
Une fois crée, le zpool peut directement être monté en tant que système de fichier, mais il est aussi possible d’y créer des dataset, qui peuvent eux-même être montés.
On peut également créer des zvol (volumes) au sein d’un zpool, qui pourra être accédé comme un périphérique bloc : il sera possible de le formater avec un autre FS.
Considérations sur la structure d’un pool et son évolution :
https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Pool%20Structure/Changing%20Pool%20Layout.html
Globalement, en cas de RAIDZ, il sera impossible de retirer un vdev (même non-raidz) du pool.
dataset
Gérés avec la commande zfs.
Représente un ensemble de données, géré comme une unité.
C’est au niveau du dataset que sont gérés les snapshots.
On peut aussi créer un dataset enfant sous un dataset parent, avec la possibilité d’hériter des propriétés du parent.
Bien que ce ne soit pas exactement la même chose, ça s’approche des subvolumes de btrfs.
snapshot
zfs snap[shot]
Forcément en read-only. Pour écrire dedans il faut faire un clone.
Toujours de la forme dataset@snapshot
Lister les pools et les datasets
zfs list
zfs list -t all
-t peut être filesystem, snapshot, volume, bookmark, all ; par défaut fs only
zfs list -j pour du json
RAIDZ et redondance
Le RAIDZ est un système de parité analogue au RAID (bien que fonctionnant différemment).
Le RAIDZ-1 contient 1 disque de parité (analogue au RAID5). Le RAIDZ-2 contient 2 disques de parité (analogue au RAID6).
Il existe aussi le RAIDZ-3 avec 3 disque de parité.
ZFS peut aussi fonctionner en mode miroir (analogue au RAID1), cette fonctionnalité est simplement appelée “mirror”.
ARC
https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Pool%20Structure/Caching.html
ZFS fait une utilisation assez intensive des caches, si disponibles.
Il y a un cache primaire de lecture en RAM, le ARC (Adaptive Replacement Cache).
On peut définir un ARC de 2nd niveau sur disque rapide (L2ARC). Il consomme aussi de la RAM, donc si on a des limites basses de RAM, il peut être contre-productif (l’ARC sera plus petit pour laisser la place à l’indexation du L2ARC). À la grosse louche, environ 1G de RAM pour 30G de L2ARC (mais ça dépend du recordsize de chaque fichier).
Voir plus bas.
Persistence ?
ZIL
ZFS Intent Log
C’est l’endroit où sont écrites les demandes d’écriture synchrones.
Par défaut, ce sont des blocs du pool ; mais on peut définir un vdev spécial dans ce but (le SLOG (Separating Intent Log), type log).
Il faut de la protection (Power-loss Protection, redondance etc) sinon des données seront perdues.
special
https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Pool%20Structure/Special%20vdev.html
vdev qui va stocker certains données spéciales ; notablement les metadonnées.
Permet de grandement limiter les random IO dans le cas de disques HDD si on met les metadonnées sur un SSD.
Attention, perdre un special vdev équivaut à perdre le pool entier !
Si le pool contient au moins un RAIDZ, il est impossible de retirer le vdev special ; il sera donc définitif.
En d’autres cas, il devrait être possible de supprimer un vdev special après son ajout.
Install
Recommandé de l’installer depuis les backports
Besoin de la section contrib
sudo apt install -t stable-backports zfsutils-linux zfs-dkms
Il y a aussi le paquet zfs-initramfs
Nécessaire pour avoir un /boot ou un / en ZFS ?
zpool
C’est un ensemble logique complet pouvant être utilisé avec ZFS. Il est constitué de 1 ou plusieurs vdev.
Au sein d’un zpool, les données sont réparties entre les différents vdev de stockage (ou de support).
Il n’y a pas de redondance au sein d’un zpool : si un seul vdev vient à manquer, l’ensemble du zpool est perdu !
C’est au sein de chaque vdev que l’on va s’assurer d’une redondance si nécessaire.
Le zpool contient directement un dataset, qui peut être monté. Il est aussi possible d’y créer des dataset enfants et sous-enfants.
Il y a un héritage des propriétés (qui peut être modifié).
Tout se gère avec la commande zpool.
vdev
Un vdev représente une unité de stockage, au sein du zpool.
Il y’a plusieurs types de vdev, etre autres :
- ceux de stockage, qui peuvent être en simple disque, en mirror (équivalent RAID1), en RAID-Z (équivalent RAID5-6)
- ceux de support :
- CACHE
- LOG
- SPECIAL
Un vdev est constitué de 1 ou plusieurs devices, qui peuvent être des périphériques blocs ou des fichiers.
ashift
ashift représente la taille de secteurs des disques d’un pool, en puissance de 2.
Défini à la création du pool, ne peut plus être modifié par la suite !
9 : 2⁹ = 512
12 : 2¹² = 4096
9 peut être intéressant pour les vieux HDD en addressage logique et physique 512, mais sinon 12 sera sûrement plus adapté et performant.
Si on ne le spécifie pas, il est détecté automatiquement. Mais il est possible que la détection soit incorrecte, notamment avec les disques 512e.
Pour la vérifier, on peut faire :
zdb -C | grep ashift
ou
zpool get ashift
Il y a aussi la commande
zpool get ashift mypool all-vdevs
qui donne le ashift de chaque vdev sous-jacent ; mais celui-ci n’a pas d’importance ; il changera si le pool est exporté puis importé. Il définit juste le niveau d’ashift qui sera utilisé pour l’autodétection si on crée un vdev dessus.
https://github.com/openzfs/zfs/issues/16838
atime
zfs get atime mypool[/dataset]
zfs set atime=off mypool
Commande zpool
Permet de gérér les pools et les vdev.
Les vdev sans chemin absolu sont cherchés dans /dev/
Création d’un pool
man zpool create
De la forme
poolname = "myzpool"
sudo zpool create -o ashift=12 -m mountpoint $poolname dev1 dev2 [redundancy] dev3 dev4 [redundancy] dev5 dev6 dev7
On peut mettre mountpoint=none
On peut spécifier une nature de redondance pour chaque vdev, puis on spécifie les devices (ou fichiers) qui entreront dans ce vdev.
Dans le cas ci-dessus, nous aurons 4 vdev : dev1, dev2, une redondance entre dev3 et dev4, et une redondance entre dev5, dev6 et dev7.
Nous aurons probalement un message d’erreur nous informant que la redondance n’est pas régulière entre les différents vdev.
La redondance peut prendre entre autres ce valeurs : mirror , raidz (équivalent à raidz1) , raidz2 , raidz3. Peut-être single ?
Le zpool est importé/monté dans le système dès sa création s’il a un point de montage.
Cas simple : un seul périphérique :
sudo zpool create $poolname /dev/disk/by-id/ata-XXX
Nommage des devices
ZFS garde le chemin du device en tant un propriété du device dans le zpool ; pour le voir :
zpool get path mypool sdX
Le nom doit être comme dans zpool status (on peut aussi utiliser l’UUID, avec -g).
C’est ici que sera cherché le device en cas de zpool online mypool sdX
Cette propriété est définie à l’import du pool.
Voi le fichier /etc/zfs/zpool.cache
Pour cette raison, il est conseillé de choisir une méthode + fiable que /dev/sdX pour définir les devices (par ex /dev/disk/by-id/).
À l’export, les données sont “oubliées” et seront redétectées à l’import suivant (il analyse les GUID pour déterminer la topologie).
Si on besoin de remettre online un disque sur un autre chemin, mais SANS arrêter le pool, il faut modifier la propriété :
zpool set path=/dev/sdY mypool sdX
Ainsi le device sera toujours nommé sdX au sein du zpool, mais il ira chercher le block /dev/sdY
On peut alors zpool online mypool sdX
Paramètres à la création
Lors de la création d’un pool, certains paramètres sont choisis définitivement.
Les principaux à mentionner me semblent être ashift et le chiffrement.
D’autres paramètres peuvent être changés par la suite, mais la modification n’affecte pas les données déjà existantes. Par exemple, la compression, ou le recordsize.
Lister les pools
zpool status
Les chiffres READ WRITE et CKSUM comptent le nombre d’erreurs de chaque catégorie sur chaque vdev.
Il y a un “watch” intégré : zpool status 1 par ex.
Sortir les données en json :
zpool status -j | jq
donne beaucoup d’infos détaillés sur chaque composant.
man zpool status
Beaucoup d’options intéressantes
-s : pour identifier les vdev lents
zpool list -v -P
Permet de voir l’usage disque de chaque pool et même de chaque vdev.
Attention, on voit l’espace total, et non l’espace utilisable. Pour un RAIDZ2, la valeur affiché ici ne tient pas compte des 2 disques de parité.
Voir zfs list pour voir l’espace utilisable.
Historique des commandes
zpool history mypool
Permet de voir l’historique des commandes ayant agi sur ce zpool.
Par défaut ça ne met que les commandes entrées par l’utilisateur ; si on veut aussi voir les autres évenemnts (achèvement d’une commande par ex.) on peut utiliser
zpool history -i mypool
Ajouter un vdev à une pool
zpool add $poolname device
Dans les vdev : attach/detach
zpool attach $poolname device new_device
permet d’ajouter un disque/fichier à un vdev.
S’il s’agit d’un miroir ou directement d’un disque, le disque sera ajouté en tant que miroir.
S’il s’agit d’un RAIDZ, le RAIDZ est agrandi en prenant en compte le nouveau disque, et en conservant son niveau fonctionnel (un raidz2 reste un raidz2, mais avec 1 disque en plus.
Pour ça, l’ensemble des données est réécrite sur le raidz
sudo zpool detach $poolname device
Permet de supprimer un disque d’un miroir ou d’un “replacing-X”.
Impossible de supprimer un disque d’un vdev en raidz ?
scrub
Consulter l’état du scrub :
zpool status mypool à côté de scan:
scan: scrub in progress since Wed Oct 14 00:26:32 2026
3.07T / 1.60T scanned, 776G / 1.60T issued at 842M/s
0B repaired, 47.32% done, 00:17:30 to go
“scanned” c’est assez rapide, c’est genre l’indexation, mais “issued” c’est la vraie vérif des données, c’est beaucoup plus long.
Je pense qu’on est à 3.07T indexés sur 1.60T réellement utilisés grâce à la dedup de très gros fichiers.
Lancer (ou continuer) un scrub :
sudo zpool scrub mypool
Mettre en pause un scrub :
sudo zpool scrub -p mypool
Annuler un scrub :
sudo zpool scrub -s mypool
Pool suspendu
Si un vdev vient à manquer, le pool est suspendu.
S’il est encore disponible (par exemple un disque qui a été déconnecté mais qui fonctionne correctement), il devrait de le rebrancher, puis d’entrer la commande
sudo zpool clean $poolname
ça devrait “resynchroniser” le pool, et remettre le compteur d’erreurs à 0 partout.
Dans mon expérience, même en déconnectant un disque en plein milieu d’une copie de fichier vers le pool, si on le reconnecte et que l’on cleane, le transfert se finit correctement et le fichier ne sera pas corrompu.
À condition que le chemin du device soit le même que précédemment ! D’où l’intérêt d’utiliser des chemins fixes (by-id).
Si le vdev est définitivement perdu, il ne sera pas possible de récupérer les données du pool.
Lister les propriétés d’une pool
zpool get all $poolname
ou plus finement
zpool get property1,property2 $poolname
Détacher une pool
sudo zpool export $poolname
Trouver et importer des pools inactives
sudo zpool import
va lister les pools détectés (et inactifs)
Par défaut, ça va chercher sur les périphériques dispos dans /dev/. Les informations concernant l’appartenance à un pool sont trouvées dans la table de partition du périphérique.
On peut spécifier un dossier ou device à chercher avec l’option -d. Nécessaire pour importer un pool créé sur des fichiers.
sudo zpool import $poolname [newpoolname]
Permet de la rendre disponible, éventuellement en changeant son nom.
Détruire (et tenter de restaurer) un pool
zpool destroy $poolname
Ceci essaye de démonter tous les datasets, puis détruit le pool (avec tous les datasets contenus). Aucune confirmation n’est demandée.
Ceci permet d’utiliser les disques qui étaient dans le pool pour un autre usage.
Cette suppression supprime les métadonnées du pool, mais les données restent intactes (tant qu’on n’écrit pas dessus).
Si la destruction est une erreur, on peut lister les pools supprimés avec :
zpool import -D
et si c’est bon, on peut les importer automatiquement avec
zpool import -a -D
Commande zfs
Sert à gérer les datasets.
Créer un dataset
zfs create -o property=value mypool/mydataset
Monter un dataset
zfs mount $poolname
va monter dans le chemin défini dans la propriété mountpoint
Lister les montages ZFS
zfs mount
ou
mount | grep "type zfs"
Lister les propriétés des datasets
zfs get all [mydataset]
ou + finement
zfs get property1,property2 [mydataset]
Les propriétés dont la source est “default” sont définies à la volée, selon les valeurs par défaut (par exemple, le mountpoint sera /datasetname).
Les propriétés définies explicitement sur le dataset auront comme source “local”, et font partie intégrante du dataset, même si celui-ci est branché sur une autre machine.
zfs list
man zfs list
zfs list -t all -r
Espace disque
zfs list -o space : vue par dataset avec la répartition entre espace utilisé par le dataset lui-même (USEDDS), par les snapshots (USEDSNAP), par les enfants (USEDCHILD) et par les réservations
zfs list -t snapshot -o name,used,refer : l’espace propre à chaque snapshot
zfs destroy -nv pool/ds@snapA%snapB : simulation de suppression d’une plage de snapshots, qui indique l’espace récupérable. Très utile pour savoir ce que libérerait un nettoyage
zpool list -v et zpool iostat -v : vue au niveau pool et vdevs
zdb -DD pool : statistiques de dedup
Définir des propriétés des datasets
sudo zfs set property=value mypool/mydataset
On peut aussi enlever une valeur explicite et remettre par défaut avec la commande
sudo zfs inherit property mypool/mydataset
Chiffrement
Il s’active au niveau du dataset (y compris le dataset racine si activé). L’activation du chiffrement est décidée à la création du dataset, et ne pourra plus être changée. S’il besoin de modifier le chiffrement du dataset, il faut en créer un nouveau et transférer les données.
À noter que certaines metadonnées ne sont pas chiffrées : nom des datasets, leurs propriétés, la structure du pool, tailles globales.
Les fichiers et metadonnées de fichiers sont chiffrés.
Il y’a par défaut un héritage du chiffrement : des datasets enfant héritent du chiffrement du parent.
Il est toutefois possible de spécifier un chiffrement différent (clé, pas, voire pas de chiffrement) lors de la création du dataset enfant (-o encryption=off).
La notion de encryptionroot désigne le niveau d’arborescence où a été définie la clé utilisée pour ce dataset.
Le chiffrement se fait avec une clé maitresse. Celle-ci est stockée directement sur le dataset, sous forme chiffrée par une clé d’enveloppe (wrapping key) ; en gros même architecture que sous LUKS.
L’algo de chiffrement (cipher) est forcément AES ; toutes les combinaisons de 128,192 et 256 bits, et des modes ccm et gcm. Cet algo n’est pas modifiable après la création du dataset chiffré.
Hors cas particulier (rétrocompatibilité, pas d’accélération hw crypto etc), le mieux est aes-256-gcm et c’est le choix par défaut (encryption=on).
L’algo choisi chiffre directement les données, et ce sera aussi celui utilisé pour chiffrer la clé maitresse.
La clé d’enveloppe peut être de format raw, passphrase ou hex. C’est la property keyformat.
Si c’est raw, c’est directement la clé d’enveloppe ; pour AES-256 elle doit faire 32 octets (soit 256b). À conserver privée !
Si c’est hex, c’est exactement comme raw, mais au format hexadecimal ; plus pratique à manipuler, permet de la gérer sous format texte (fichier lisible, C/C etc). Fera donc 64 caractères hexadecimaux.
Si c’est passphrase, alors la clé est dérivée de la passphrase (salted), comme une graine (par l’algo pbkdf2-hmac-sha1), avec un certain nombre d’itérations (pbkdf2iters, par défaut 350000). L’entropie de la clé dépend alors de la sécurité/longueur de la passphrase, et le nombre d’itérations sert à ralentir le bruteforce (son efficacité est toutefois relative ; il faut une bonne passphrase).
keylocation : l’endroit où va être récupérée la clé d’enveloppe.
Ça peut être de la forme prompt, file:///path/to/keyfile ou https://server.example.com/key-file
C’est uniquement une indication ; peut être surchargé par zfs load-key -L
Il est possible de changer le chiffrement de la clé d’enveloppe (keyformat,keylocation,pbkdf2iters) :
zfs change-key -o keyformat=raw -o keylocation=file:///root/new.key
Si on utilise un fichier clé, celui-ci doit nécessairement être d’exactement 32 octets (soit 236 bits). L’algo utilisé est AES-256. Pour en créer une :
dd if=/dev/urandom of=./zfs_key bs=32 count=1
Pour un ficher hex on peut faire :
``
Créer dataset chiffré
Par clé :
sudo zfs create mypool/datacrypt -o encryption=on -o keyformat=raw -o keylocation=file:///path/to/keyfile
Ouvrir un dataset chiffré
zfs load-key
zfs load-key -L
Voir le statut de chiffrement des pools et datasets
Uniquement les datasets chiffrés :
zfs list -r -o name,encryption,encryptionroot,keyformat,keystatus,keylocation | awk '$2 != "off"'
Uniquement les encryptionroot (datasets qui ont leur propre clé) :
zfs list -r -o name,encryption,encryptionroot,keyformat,keystatus,keylocation | awk '$1 == $3'
Uniquement les datasets verrouillés :
zfs list -r -o name,encryption,encryptionroot,keyformat,keystatus,keylocation | awk '$5 == "unavailable"'
Uniquement les déverrouillés :
zfs list -r -o name,encryption,encryptionroot,keyformat,keystatus,keylocation | awk '$5 == "available"'
Autre possibilité, avec tous les datasets :
zfs get name,encryption,encryptionroot,keyformat,keystatus,keylocation [mypool/dataset]
Autre propriété qui existe : pbkdf2iters (nombre d’itérations) .
keystatus : est-ce que la clé est chargée en RAM ?
Pour entrer la clé manuellement :
sudo zfs load-key mypool/datacrypt
dataset racine chiffrée
zdb
ZFS debugger
Outil très puissant, qui fonctionne principalement en lecture seule, mais a certaines options d’écriture.
Certaines opérations demandent beaucoup d’IO (lecture/vérif de l’ensemble du FS par exemple).
À utiliser idéalement sur pool non-importé.
Lancée sans argument, sudo zdb équivaut à sudo zdb -C et affiche un récap texte des pools.
On y voit notamment txg, qui est un suivi incrémentiel des transactions.
On peut y voir aussi not_present: 1 pour un children absent d’un vdev.
sudo zdb MyPool : va instantanément lancer une analyse en profondeur du pool, scannant l’ensemble des données, et monopolisant les IO.
Il n’a d’intérêt que pour debugger un système ZFS corrompu, qu’on ne peut pas importer etc.
Un simple scrub est suffisant lorsque le système fonctionne correctement et s’importe bien.
sudo zdb -l /dev/sdX
Va lire les infos d’appartenance à un pool de /dev/sdX.
On peut notamment y voir le numéro de txg (transactions groups), qui représente l’avancée des écritures dans le temps :
sudo zdb -l /dev/sdX | grep -i " tx"
Si le disque fait partie d’un pool importé, la valeur est le txg lors de l’importation.
Si le disque est hors-ligne, c’est la valeur du dernier txg écrit dessus.
Si le disque a été débranché quelques temps, on peut comparer son avancement avec celui du pool importé en cours de fonctionnement :
sudo zdb -u MyZpool | grep -i "txg "
tail -n 3 /proc/spl/kstat/zfs/MyZpool/txgs
while [ 1 ]; do for i in $(ls /dev/mapper/); do echo $(sudo zdb -l $i | grep -i " tx"); done ; sleep 1 ; done
ARC
https://openzfs.github.io/openzfs-docs/Basic%20Concepts/Pool%20Structure/Caching.html
Le cache ARC est un mécanisme de mise en RAM de certaines données ; notamment les données très récentes et les données fréquemment accédées.
La quantité max octroyée au cache ARC dépend de la quantité de RAM mais peut être assez élevée.
Pour voir la quantité max et la quantité utilisée, on peut passer par htop en customisant l’affichage.
zarcsummary
zarcstats
Sinon on peut voir le max avec
cat /proc/spl/kstat/zfs/arcstats | grep c_max
et la quantité actuellement utilisée avec
cat /proc/spl/kstat/zfs/arcstats | grep -E "^size"
Il faut diviser les valeurs par (1024³) pour avoir les valeurs en Go, et (1024²) pour avoir les valeurs en Mo.
Activer ou désactiver ARC
Cette fonctionnalité peut être désactivée pour certains dataset si nécessaire (utile par exemple pour des tests de perf fio).
On peut vérifier le statut d’activation du cache avec :
zfs get all | grep -i primarycache
et le désactiver avec
sudo zfs set primarycache=none monpool/fio-test
ou le réactiver avec
sudo zfs set primarycache=all monpool/fio-test
ou par défaut avec
sudo zfs inherit primarycache monpool/fio-test
L2ARC
Le cache ARC de niveau 2 est un device spécial (typiquement un SSD), qui n’est pas obligatoire, et dans lequel se déverse le cache RAM qui devient trop vieux.
Pour voir si on en a un, il faut regarder la sortie de
zpool status
et voir si un device cache est mentionné.
On peut aussi faire
cat /proc/spl/kstat/zfs/arcstats | grep l2_size
pour avoir la taille en octet.
Si on souhaite le désactiver, essayer comme ci-dessus avec secondarycache au lieu de primarycache.
Santé et remplacement d’un RAIDZ-2
Dans cet exemple, j’ai un pool constitué d’un seul vdev, lui-même constitué de 8 fichiers en RAIDZ-2.
J’ai volontairement corrompu ce vdev en supprimant 2 fichiers.
Lorsque l’on liste les pools et les vdev, le pool ainsi que le vdev se trouvent dans l’état DEGRADED.
Chacun des 2 devices (en l’occurence fichiers) se trouve dans l’état FAULTED.
FAULTED signifie que le device sous-jacent est toujours pris en compte dans le vdev, mais inaccessible ou défectueux (par exemple disque en panne, ou débranché, ou fichier supprimé).
Il y a aussi l’état OFFLINE, qui signifie que le device sous-jacent a été sorti du vdev, qui est en attente d’un remplacement pour ce device.
On peut volontairement passer un device en OFFLINE avec la commande :
sudo zpool offline $poolname device
Aussi état “UNAVAIL”. Dit quel était le précédent device (was /dev/mapper/sde)
Lorsqu’un device est sain (“ONLINE”), son nom/chemin est indiqué dans la sortie de zpool status ou zpool list -v -P.
Lorsqu’un device est absent (FAULTED, OFFLINE ou UNAVAIL), ce sera son GUID qui sera indiqué.
On peut obtenir les GUID de tous les device, même les sains, avec zpool list -v -P -g.
Pour remplacer une disque/fichier offline ou faulted :
sudo zpool replace $poolname $oldGUID /dev/sdX
sudo zpool replace $poolname $oldGUID ./file.dat
Ça devrait automatiquement lancer un resilvering. Pendant ce temps, un device replacing-1 apparaît dans le vdev, qui a lui-même son propre GUID et est composé de l’ancien et du nouveau device.
Il peut y avoir l’erreur cannot replace OLD_GUID with sdX: sdX is busy
J’ai eu ça en essayant de réajouter un disque qui avait déjà fait partie du pool. Même après wipefs -af sur les partitions puis sur la table de partition, le disque restait “busy”.
J’ai résolu l’erreur en réinitialisant le SSD comme ceci
Je suppose qu’en écrivant l’ensemble du SSD avec des 0 ça peut fonctionner aussi.
Essayer zpool labelclear ?
Deduplication
Permet d’économiser de l’espace de stockage lorsque l’on stocke plusieurs fois des blocs de données identiques.
Nécessiter beaucoup de ressources : beaucoup de RAM, et il est conseillé d’avoir des SSD dédiés pour stocker la table de dédup (DDT).
Globalement il n’est pas conseillé de l’activer, sauf cas spécifiquement adapté.
zdb -S MyPool pour simuler l’impact (analyse tout le pool)
Overhead
https://wintelguy.com/2017/zfs-storage-overhead.html
L’espace “slop space” est réservé par le FS pour être sûr d’avoir de la place pour certaines opérations critiques, même en cas de saturation du stockage.
Par défaut il devrait être à 1/32e du stockage total.
Monitoring
Voir l’activité des disques toutes les 1 sec :
qqzpool iostat 1
man zpool iostat
zpool status permet de voir (ligne scan:) si une opération ZFS est en cours (scrub, resilver), ou de voir la dernière date du scrub
CoW
Le Cow ne peut pas être désactivé sur ZFS.
Pour éviter les dégradations de performances, cela se fait via la config de ZFS.
Si on a des zvol, il faut faire correspondre volblocksize au FS invité (par défaut 128k ?).
Pour les VMs ou les DB, on joue sur recordsize.
Selon la criticité des données, on peut désactiver les requêtes synchrones ; elle sont alors groupées en RAM et flushées toutes les 5 secondes ; ceci expose à une perte de données.
zfs set sync=disabled tank/vm-dataset