ZFS over iSCSI suite.

Ce billet fait suite à celui-ci où je constate un dysfonctionnement majeur.
Je ne trouve pas d'anomalie côté client, je n'en trouve pas côté infrastructure réseau reste le serveur.
Alors que puis-je constater ?

Depuis le client Windows, malgré des benchmarks et des tests de transferts satisfaisants immédiatement après la création du volume iSCSI, dans la pratique quelque chose cloche lors d'un transfert de données de "grande" ampleur, ici sur un ensemble de 500 Go en cours de transfert :

Des paquets sont envoyés puis il y a une pause avant la reprise et ce cycle se répète. Je pense à du cache ou à de l'occupation CPU mais je ne trouve pas d'anomalies de ce côté non plus.

Côté serveur, en regardant les propriétés iscsi et nfs je commence à entrevoir des incohérences

Alors les informations ne sont pas très claires, est-ce qu'on parle en premier de TiB et de l'autre de To ? Quoi qu'il en soit il y a également un avertissement. Je vais donc partir sur la piste d'un mauvais dimensionnement de l'espace iscsi offert.

Je détruis le volume zfs offert en partage iscsi, je coupe le service iscsi, commente le fichier de configuration des cibles iscsi.

Sauf que ... le pool zfs affiche un taux d'occupation élevé malgré la suppression du volume ?
Les commande zfs list et zpool list affichent des valeurs différentes mais toujours une occupation de l'espace disque sans données

D'ailleurs en parlant de valeurs différentes, quand on rentre dans le détail avec zfs list -o space on obtient encore une autre valeur

La propriété USEDCHILD affiche 522 Go ou GiB ? d'occupés
La documentation de cette propriété indique qu'elle est spécifique aux snapshots, or en état actuel je ne peux pas avoir de snapshots puisque je n'ai plus de dataset sur ce pool ?
Vérification :

La destruction, comme je l'ai fait, d'un dataset entraine obligatoirement la destruction des snapshots. Donc qu'est-ce qui occupe de la place ici le mystère reste entier ? D'autant plus qu'en y regardant plus tard, la taille occupée évolue !

Je rappèle que le client Windows est éteint, le daemon tgtd (iscsi) est inactif et qu'il n'y a pas de transactions zfs en cours. USEDCHILD semble "dégonfler" tout seul. Cherchons donc ce qui peut expliquer celà.
En comparant les propriétés de deux pools, je m'aperçois qu'à un moment j'avais forcé la compression sur le pool qui pose problème, cela est-il la cause ?

J'ai beau couper la compression et attendre d'éventuelles transactions, le taux d'occupation ne diminue pas pour autant.
Las et à cours d'idées, je me résous à détruire le pool pour le recréer avec des paramètres par défaut. ça ne me dira pas ce qui clochait hélas.

Et là je prends conscience d'une chose :
physiquement le pool est composé de 5 disques de 238 Go soit 1.19 To
Mais s'agissant de "Raid5" j'ai de l'espace perdu pour les CRC, donc en fait je ne dispose que de 4*238 soit 952 Go
Après recréation du pool je lis "923G available", dans mon test précédant j'avais alloué un espace iscsi de 1.1 To. Avec une compression possible, se peut-il que les latences observées étaient dues à cette compression ? C'est peut être pour cela que j'obtenais un message d'erreur quand je souhaitais créer l'espace, mais j'ai forcé avec le fameux commutateur "-s"... Il est donc fort probable que le système m'avertissait d'une impossibilité, la faute à mon incompréhension entre les tailles disponibles différentes affichées par zfs list et zpool list ?