Optimiser le Recordsize ZFS : La variable “cachée” pour des gains de performance massifs

Si vous explorez l’univers de ZFS, vous avez probablement passé des heures à débattre des niveaux de RAIDZ ou de la taille de la RAM. Mais il existe un réglage qui passe souvent inaperçu, alors qu’il a plus d’impact sur vos IOPS que n’importe quel autre : Le Recordsize.

Que vous gériez un cluster Proxmox, un serveur Plex ou une base de données haute performance, utiliser un mauvais recordsize, c’est comme conduire une Ferrari en première vitesse.

Qu’est-ce que le Recordsize ZFS ?

Le recordsize est la taille maximale des blocs de données que ZFS écrit sur votre pool. Par défaut, ZFS utilise 128K.

ZFS est un système de fichiers à taille de bloc variable. Si vous écrivez un fichier de 4K, il n’occupera que 4K sur le disque. Cependant, si vous écrivez un fichier de 1 Mo, ZFS le découpera en morceaux de 128K (par défaut).

Pourquoi est-ce crucial ?

• Petit recordsize (ex: 4K ou 16K) : Idéal pour les bases de données (MySQL, PostgreSQL) car cela correspond à leur manière de communiquer avec le disque. Cela évite l'”Amplification d’Écriture”.

• Grand recordsize (ex: 1M) : Incroyable pour les fichiers multimédias ou les sauvegardes. Cela augmente le débit (throughput) et améliore les ratios de compression.

Le piège Proxmox et des VM

Si vous faites tourner des machines virtuelles sur ZFS, vous souffrez peut-être d’une pénalité de performance sans le savoir. Les images disques de VM (zvols) utilisent souvent un volblocksize de 8K par défaut.

Si votre pool ZFS est optimisé pour 128K, chaque fois que votre VM modifie un petit morceau de donnée de 8K, ZFS doit effectuer un cycle de lecture-modification-écriture plus lourd que nécessaire. Cela génère de la latence et des “iowait”.

La règle d’or pour les VM : Alignez votre volblocksize sur la taille de cluster du système de fichiers interne de votre VM. Pour la plupart des VM Linux, 16K ou 64K est souvent le compromis idéal.

Comment tester vos performances (La méthode scientifique)

Ne devinez pas : testez. Pour vérifier si votre recordsize est optimal, utilisez FIO (Flexible I/O Tester). Voici une commande pour tester les écritures aléatoires :

fio --name=random-write --ioengine=libaio --rw=randwrite --bs=4k --size=2G --numjobs=1 --iodepth=64 --runtime=60 --time_based --output-format=json --filename=/votre/chemin/zfs/testfile

Une fois le test terminé, copiez le JSON et collez-le dans notre FIO Results Viewer pour analyser vos IOPS et votre latence p99.

Verdict : Quelle taille choisir ?

1. Torrents & Médias volumineux : Optez pour 1M. Cela réduit la charge des métadonnées et accélère vos “scrubs”.

2. Partage de fichiers général : Gardez le défaut de 128K.

3. Bases de données : Alignez sur la taille de page (généralement 16K).

4. Virtualisation (Proxmox/KVM) : Utilisez 16K ou 64K.

🔬 Analyse Avancée : Le coût des métadonnées et de l’Ashift

Pour aller plus loin, il faut considérer la valeur Ashift (taille de bloc physique de vos disques). La plupart des disques modernes utilisent des secteurs de 4K natifs (ashift=12).

Si vous réglez un recordsize trop petit (comme 4K) sur un pool RAIDZ large, vous risquez une inefficacité d’espace massive. Comme ZFS doit stocker la parité pour chaque enregistrement, la parité peut finir par occuper autant de place que la donnée elle-même !

Conseil pour les utilisateurs de NVMe : Sur des SSD NVMe performants, n’hésitez pas à tester un recordsize=16K pour vos disques système. L’absence de temps de recherche (seek time) permet à ZFS de gérer de petits records sans perte de performance sensible, tout en prolongeant la durée de vie de vos cellules SSD.