ZFS L2ARC sur SSD SATA : quand cela vaut la peine

Ce qu’est vraiment L2ARC (et ce que ce n’est pas)

Le cache ZFS commence par l’ARC : un cache en RAM qui contient données et métadonnées. L’ARC est rapide, adaptatif et opportuniste.
Quand l’ARC est trop petit pour votre working set, ZFS peut l’étendre sur un deuxième niveau : le L2ARC, généralement sur SSD.

Ce qu’est L2ARC

• Un cache de lecture pour les données sorties de l’ARC. Ce n’est pas « une couche SSD magique ». C’est une seconde chance de servir des lectures sans aller sur disques rotatifs.
• Un stockage persistant contenant des blocs mis en cache, indexés par l’ARC. Le SSD contient les blocs ; la RAM contient l’index (entêtes) qui indique à ZFS ce qu’il y a sur le SSD.
• Idéal pour les relectures répétées. Si votre charge de travail ne relit pas les blocs, L2ARC devient un tapis roulant d’écritures avec peu de retour.

Ce que L2ARC n’est pas

• Ce n’est pas un cache d’écriture. C’est le rôle du SLOG pour les écritures synchrones, et encore seulement pour le journal d’intention, pas pour « accélérer toutes les écritures ».
• Ce n’est pas un substitut à la RAM. L’ARC vit en RAM et fait le travail lourd. L2ARC est un complément, pas un remplacement.
• Ce n’est pas une cure pour une mauvaise conception de pool. Si votre layout de vdevs est mauvais pour les lectures aléatoires, L2ARC peut masquer des symptômes brièvement, puis laisser la maladie intacte.

L’aspect le plus mal compris de L2ARC est le coût en RAM. Vous n’obtenez pas « 1 To de cache gratuit » seulement parce que les SSD SATA sont bon marché.
L’index L2ARC consomme de la mémoire, et affamer l’ARC pour nourrir le L2ARC, c’est comme sauter le petit-déjeuner pour acheter une ceinture plus grande.

Une citation utile à garder en tête pendant que vous ajustez les caches : « L’espoir n’est pas une stratégie. » — Vince Lombardi.
Elle s’applique aussi aux performances de stockage, mais avec plus d’iostat.

Faits intéressants et historique (parce que le contexte change les décisions)

1. L’ARC précède la culture cloud actuelle du “tout mettre en cache”. ZFS est livré avec l’ARC au milieu des années 2000, quand la RAM coûtait suffisamment pour faire pleurer les ingénieurs.
2. L2ARC a été conçu pour des disques lents. Les premiers déploiements ZFS utilisaient souvent des HDD SATA ; L2ARC était un pansement pratique pour les lectures aléatoires sans reconstruire les pools.
3. L2ARC se réchauffait lentement après un reboot. Le comportement initial exigeait de repeupler le cache après chaque redémarrage ; OpenZFS a ajouté plus tard des fonctionnalités pour reconstruire l’état plus vite (dépendant de la plateforme).
4. L2ARC est « écrit » au fur et à mesure qu’il est alimenté, pas répliqué par défaut. Si vous perdez le périphérique cache, la sécurité des données n’est pas affectée ; seules les performances retombent au niveau de base.
5. L’ARC peut mettre en cache les métadonnées de manière agressive. Pour beaucoup de charges réelles, la mise en cache des métadonnées (parcours de répertoires, recherche de petits fichiers) domine la sensation de rapidité.
6. ZFS a désormais plusieurs rôles de « stockage rapide ». L2ARC, SLOG, special vdevs, et même les tables de déduplication exigent chacun des caractéristiques SSD différentes.
7. Les SSD SATA ont réduit l’écart sur le débit, pas sur la latence. L’interface SATA plafonne la bande passante et tend à avoir une latence plus élevée que NVMe ; L2ARC est souvent sensible à la latence.
8. L2ARC peut augmenter le nombre total de lectures servies rapidement, mais aussi augmenter les écritures totales. Nourrir le cache est une charge d’écriture à laquelle vous vous portez volontaire.

Blague n°1 : Ajouter un L2ARC pour réparer un pool lent, c’est comme installer un turbo sur une camionnette à roues carrées. Ça fera du bruit. Ça ne vous rendra pas heureux.

Quand un L2ARC sur SSD SATA a du sens

Un L2ARC sur SSD SATA vaut la peine quand vous avez trois conditions simultanées :
(1) une charge orientée lecture, (2) un working set qui ne tient pas dans l’ARC, et (3) suffisamment de RAM disponible pour héberger l’index L2ARC sans évincer l’ARC utile.
Si une de ces conditions manque, vous achetez surtout de la complexité.

Charges de travail qui ont tendance à en bénéficier

• Tempêtes de lectures en virtualisation : Beaucoup de VM démarrant ou patchant en parallèle, touchant à nouveau des blocs OS et bibliothèques partagées.
• Dashboards analytiques / BI : Balayages répétés des mêmes jeux de données, souvent en rafales pendant les heures d’activité.
• Fleets web/app avec beaucoup de lectures de code : Les déploiements à froid peuvent provoquer du thrashing, mais l’état steady relit souvent les mêmes binaires et templates.
• Serveurs de fichiers avec contenu partagé « chaud » : Bibliothèques CAO, artefacts de build, toolchains partagées que de nombreux clients lisent de manière répétée.

Signaux qui font de vous un candidat

• Les IOPS de lecture disque sont élevés et principalement aléatoires.
• Le taux de hit ARC est correct mais plafonné parce que le working set est plus grand que la RAM.
• La latence de lecture est votre goulot, pas le CPU, pas le réseau, pas les écritures synchrones.
• Votre périphérique L2ARC peut soutenir des écritures sans mourir prématurément ni se throttler sous l’alimentation du cache.

Le L2ARC sur SATA est aussi une bonne « solution provisoire » en réalité d’entreprise : vous pouvez souvent ajouter quelques SSD SATA plus vite que d’obtenir un budget pour « reconstruire le pool avec plus de vdevs »
ou « migrer vers NVMe ». Ne confondez pas « rapide à mettre en œuvre » et « architecturalement correct ».

Quand cela n’aidera pas (et quoi faire à la place)

Ça n’aidera pas si vous êtes lié par les écritures

Si les utilisateurs se plaignent pendant les ingestions, sauvegardes, grosses écritures séquentielles ou pics de commits de bases, L2ARC ne vous sauvera pas.
L2ARC n’accélère pas les écritures, et il peut voler des ressources aux écritures en ajoutant des écritures de fond pour alimenter le cache.

Faites plutôt : évaluez le SLOG pour la latence des écritures synchrones ; ajoutez des vdevs pour les IOPS d’écriture ; ajustez recordsize ; vérifiez les réglages sync et les patterns fsync applicatifs.

Ça n’aidera pas si votre charge est majoritairement à passage unique

L2ARC sert les relectures. Si vous parcourez des logs une seule fois, scannez des backups une fois, ou exécutez de l’ETL touchant chaque bloc une fois par jour, L2ARC se remplira de données que vous ne relirez jamais.
C’est juste de l’amplification d’écriture avec un sens du devoir.

Faites plutôt : ajoutez de la RAM (ARC plus grand), ajoutez des plateaux/vdevs, ou déplacez le dataset chaud vers un special vdev ou un pool rapide.

Ça n’aidera pas si la topologie du pool est le vrai goulot

Un vdev RAIDZ unique avec de gros HDD est excellent pour la capacité, pas pour les IOPS aléatoires. L2ARC peut réduire les lectures aléatoires, mais il ne changera pas la capacité fondamentale du pool à servir les misses.
Si votre taux de misses reste élevé, vous êtes toujours soumis à la latence HDD.

Faites plutôt : redessinez le layout de vdev (plus de vdevs, mirrors pour IOPS), ou placez les datasets véritablement chauds sur SSD/NVMe.

Ça n’aidera pas si vous manquez de mémoire

Si l’ARC rétrécit déjà sous la pression mémoire (containers, JVM, bases, ou tout simplement trop peu de RAM), L2ARC peut empirer la performance en ajoutant de l’overhead.
Le système passera son temps à jongler entre caches au lieu de servir des lectures.

Faites plutôt : ajoutez de la RAM d’abord. L’ARC est généralement le gain de performance le moins cher et le plus rapide dans l’univers ZFS.

Blague n°2 : L2ARC sur un hôte en manque de RAM, c’est comme louer un box de stockage parce que votre maison est en désordre. Vous ne retrouverez toujours pas vos clés.

Comment L2ARC fonctionne en pratique : montée en chauffe, alimentation et misses

Le cycle de vie d’un bloc en cache

Un bloc est lu. S’il est utilisé suffisamment, l’ARC le conserve. Quand l’ARC a besoin d’espace, certains blocs sont évincés.
Les blocs évincés sont candidats au L2ARC : ZFS peut les écrire sur le SSD pour que des lectures futures tombent sur L2ARC au lieu du disque.

Cela implique deux réalités importantes :

• L2ARC est peuplé par éviction. Si l’ARC ne se remplit jamais, L2ARC reste surtout inactif. Si l’ARC churne, L2ARC est alimenté agressivement.
• Le temps de montée en chauffe compte. Vous n’ajoutez pas L2ARC et vous gagnez instantanément. Le cache doit être rempli des bons blocs, et cela prend du temps réel de la charge.

Montée en chauffe après redémarrage : la douleur pratique

Beaucoup d’environnements redémarrent pour des mises à jour kernel, firmware, ou le moment « pourquoi le BMC hurle ». Si L2ARC ne reconstruit pas un état utilisable après reboot sur votre plateforme/config,
vous ressentirez un creux de performance jusqu’à ce que le cache se repeuple. C’est pourquoi certaines équipes jurent que L2ARC « ne sert à rien » — elles mesurent juste après un reboot et concluent.

Nourrir L2ARC coûte des E/S

ZFS écrit dans L2ARC en arrière-plan. C’est de la bande passante d’écriture sur le SSD, plus du CPU et de la RAM pour la tenue des comptes.
Si le SSD est un modèle consommateur SATA avec de faibles performances soutenues et un throttling thermique agressif (oui, certains SSD SATA le font aussi),
le cache peut devenir auto-limitant : il n’accepte plus assez vite de nouveaux blocs mis en cache pour rester utile.

La latence compte plus que la bande passante

Les hits L2ARC évitent la latence HDD. Très bien. Mais la latence d’un SSD SATA reste bien supérieure à celle de l’ARC. Donc L2ARC est mieux vu comme « plus rapide que HDD, plus lent que la RAM ».
Si votre charge est extrêmement sensible à la latence (bases de données, systèmes interactifs), et que les misses sont fréquents, vous pourriez avoir besoin de NVMe ou de plus de RAM.

Dimensionnement et choix de SSD SATA sans se ridiculiser

Commencez par la règle ennuyeuse : ajoutez de la RAM avant le L2ARC

Les hits ARC sont la norme d’or. Ajouter de la RAM augmente l’ARC sans coût E/S supplémentaire et avec une complexité minimale. Si vous pouvez ajouter de la RAM, faites-le en premier.
L2ARC est pour le cas où la RAM est déjà « raisonnable » et que le working set reste trop grand.

Quelle taille pour L2ARC ?

Dimensionnez-le pour le working set de relectures qui ne tient pas dans l’ARC, pas pour « le SSD qu’on avait dans le tiroir ».
Un L2ARC de 4 To sur une machine avec une RAM modeste peut être contre-productif : vous brûlez de la mémoire pour l’indexation et vous ne mettez pas en cache les bonnes choses assez vite.

Pratiquement :

• Petit et efficace bat énorme et inactif. Commencez par quelque chose comme 5–10× la taille de votre ARC pour L2ARC seulement si vous avez la marge mémoire et une charge prouvée de relectures.
• Surveillez l’overhead et le taux de hits. Si le ratio de hits L2ARC reste bas, plus grand ne le réparera pas ; ce sera juste une machine à misses plus coûteuse.

Choisissez le SSD SATA comme si vous attendiez des abus (parce que c’est le cas)

L2ARC écrit en continu pour beaucoup de charges. Les SSD SATA grand public peuvent convenir pour un cache léger, mais en production ils sont souvent le maillon faible :
endurance d’écriture limitée, comportement d’écriture soutenue imprévisible quand le cache SLC est épuisé, et quirks firmware.

Ce que vous voulez :

• Protection contre la perte d’alimentation (PLP) si possible. Ce n’est pas tant pour l’intégrité des données (le cache est jetable), mais pour éviter des comportements étranges et des corruptions sous coupure brutale.
• Performance d’écriture soutenue décente. Pas des chiffres de pic ; cherchez des écritures stables sur le long terme.
• Endurance adaptée à votre taux d’alimentation. Si votre feed écrit des centaines de Go/jour, planifiez l’endurance en conséquence.
• Stabilité thermique. Un SSD SATA coincé derrière un panneau sans flux d’air se throttlera et sabordera votre taux de hits.

Un dispositif ou deux ?

Les périphériques L2ARC ne sont typiquement pas mis en miroir. Perdre un périphérique L2ARC n’est pas une perte de données ; c’est une perte de performance.
Cela dit, si votre plateforme supporte plusieurs dispositifs cache, répartir L2ARC sur deux SSD peut aider la bande passante et réduire la contention sur un seul périphérique.
La question opérationnelle est : pouvez-vous détecter une défaillance rapidement et remplacer sans drame ?

Ne confondez pas L2ARC avec un special vdev

Un special vdev (là où il est supporté/utilisé) peut stocker métadonnées et petits blocs sur SSD, ce qui peut être transformationnel pour les charges de petits fichiers.
Mais ce n’est pas un « cache ». Il devient partie intégrante du pool ; s’il meurt et n’est pas redondant, vous pouvez perdre des données. C’est un engagement d’un autre ordre.
L2ARC est jetable par conception.

Procédure de diagnostic rapide

Quand la performance est mauvaise, vous n’avez pas le temps d’un débat philosophique sur le caching. Il faut localiser le goulot vite.
Voici l’ordre qui tend à fournir des réponses en minutes, pas en jours.

1) Confirmez quel type de douleur c’est : latence lecture, latence écriture, CPU ou mémoire

• Vérifiez la latence et l’utilisation I/O du pool.
• Vérifiez la taille de l’ARC et la pression d’éviction.
• Vérifiez si la charge est fortement orientée écriture synchrones.

2) Si limité par la latence de lecture, déterminez si c’est des misses de cache ou des hits lents

• Le taux de hit ARC est-il élevé ? Vous n’avez probablement pas besoin de L2ARC ; il vous faut plus de CPU, accélérer le checksum, ou régler l’application.
• Taux de hit ARC moyen/faible et disques occupés ? Candidat pour augmentation d’ARC, L2ARC, ou refonte du pool.
• Taux de hit L2ARC faible après montée en chauffe ? La charge ne relit pas ; n’alimentez pas la bête inutilement.

3) Si vous considérez L2ARC, validez le comportement du SSD sous écritures soutenues

• Regardez les débits d’alimentation L2ARC et la bande passante d’écriture du SSD.
• Vérifiez SMART, l’usure et les compteurs d’erreurs.
• Confirmez que le SSD ne sature pas le contrôleur SATA ou ne partage pas des voies limitantes avec d’autres périphériques.

4) Re-testez pendant la même fenêtre de charge

L2ARC dépend de la charge et du temps. Mesurez pendant la période chargée qui pose problème, pas à 2h du matin quand tout est froid et calme.

Tâches pratiques : commandes, sorties, décisions (12+)

Le but de ces tâches est simple : vous lancez une commande, lisez la sortie et prenez une décision. Pas de mysticisme. Tous les exemples supposent un système Linux avec OpenZFS.
Remplacez les noms de pool/dataset pour correspondre à votre environnement.

Tâche 1 : Identifier si le pool est limité par la latence de lecture

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.3T  7.10T    980    140  92.1M  10.8M
  raidz2-0                  12.3T  7.10T    980    140  92.1M  10.8M
    sda                         -      -    160     25  15.1M   2.0M
    sdb                         -      -    165     23  15.3M   1.9M
    sdc                         -      -    162     24  15.2M   2.0M
    sdd                         -      -    161     22  15.1M   1.8M
    sde                         -      -    165     23  15.2M   1.9M
    sdf                         -      -    167     23  15.2M   1.9M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Les lectures dominent les opérations. Si les utilisateurs signalent des lectures lentes et que les disques sont occupés, le caching peut aider.
Décision : Poursuivre les vérifications ARC/L2ARC ; ne foncez pas vers SLOG.

Tâche 2 : Vérifier la latence directement (le test « est-ce les disques ? »)

cr0x@server:~$ iostat -x 2 3
Linux 6.6.0 (server)  12/26/2025  _x86_64_  (24 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.12    0.00    2.04    9.55    0.00   82.29

Device            r/s     w/s   rMB/s   wMB/s  avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda             128.0    20.1    15.1     2.0    136.5     8.20   58.2   60.1   46.3   7.6   99.5
sdb             131.2    19.4    15.3     1.9    135.9     8.05   56.7   59.0   44.8   7.4   99.1

Ce que cela signifie : Await ~55–60ms et %util ~99% indiquent que les disques sont saturés. C’est la douleur classique des lectures aléatoires sur vdevs HDD.
Décision : Si la charge re-lit des données, L2ARC peut réduire les lectures disque ; sinon vous avez besoin de plus de vdevs ou de stockage plus rapide.

Tâche 3 : Vérifier la taille et la pression de l’ARC

cr0x@server:~$ arcstat 2 3
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c  avail
12:01:10  9820  2810     28   420    4  2390   24    95    1   38G   48G   12G
12:01:12 10110  3120     30   455    4  2665   26    98    1   38G   48G   11G
12:01:14  9905  3010     30   440    4  2570   26    92    1   38G   48G   11G

Ce que cela signifie : L’ARC est ~38G avec une cible (c) 48G ; le taux de miss ~28–30% est significatif.
Décision : Si la RAM peut être augmentée, faites-le. Sinon, L2ARC pourrait aider — vérifiez ensuite si la charge relit et si L2ARC est déjà présent.

Tâche 4 : Vérifier si L2ARC existe et comment il se comporte

cr0x@server:~$ arcstat -f time,read,miss,arcsz,l2hits,l2miss,l2read,l2asize 2 3
    time  read  miss  arcsz  l2hits  l2miss  l2read  l2asize
12:02:20  9820  2810   38G     620    2190    6200     480G
12:02:22 10110  3120   38G     700    2420    7100     480G
12:02:24  9905  3010   38G     655    2355    6600     480G

Ce que cela signifie : L2ARC existe (l2asize 480G). Des hits L2 sont présents mais pas dominants.
Décision : Si l2hits augmentent pendant la charge et que les lectures disque décroissent, L2ARC aide. Si l2hits restent proches de zéro après heures/jours, c’est probablement inutile.

Tâche 5 : Valider la présence du périphérique L2ARC dans ZFS

cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 05:22:11 with 0 errors on Sun Dec 21 03:10:12 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
        cache
          ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A  ONLINE       0     0     0

errors: No known data errors

Ce que cela signifie : Le SSD est attaché en périphérique cache.
Décision : Si vous dépannez, vous savez maintenant quel périphérique physique vérifier (SMART, câblage, contrôleur).

Tâche 6 : Ajouter un SSD SATA comme L2ARC (avec prudence)

cr0x@server:~$ sudo zpool add tank cache /dev/disk/by-id/ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            sda                     ONLINE       0     0     0
            sdb                     ONLINE       0     0     0
            sdc                     ONLINE       0     0     0
            sdd                     ONLINE       0     0     0
            sde                     ONLINE       0     0     0
            sdf                     ONLINE       0     0     0
        cache
          ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A  ONLINE       0     0     0

Ce que cela signifie : Le vdev cache est ajouté.
Décision : Documentez le changement et lancez une fenêtre de mesure. Si vous ne voyez pas d’amélioration, ne le gardez pas « parce que ça semble bien ».

Tâche 7 : Vérifier si la mémoire est comprimée (L2ARC peut aggraver cela)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           128Gi        96Gi       2.1Gi       1.2Gi        30Gi        18Gi
Swap:           16Gi       3.5Gi        12Gi

Ce que cela signifie : La mémoire disponible n’est que de 18Gi, le swap est utilisé. L’ARC peut se battre avec les applications.
Décision : Si le système swappe sous charge, ajouter L2ARC est un signal d’alerte. Réglez la pression mémoire d’abord (RAM, placement des workloads, limites ARC).

Tâche 8 : Vérifier les limites ARC (empêcher ZFS de manger tout l’hôte)

cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_max
68719476736
cr0x@server:~$ cat /sys/module/zfs/parameters/zfs_arc_min
17179869184

Ce que cela signifie : ARC max est 64GiB, min 16GiB (valeurs en octets).
Décision : Sur des hôtes à usage mixte, limitez l’ARC pour laisser une marge. Si vous ajoutez L2ARC, vous pouvez avoir besoin de plus de marge, pas moins.

Tâche 9 : Vérifier le comportement d’alimentation L2ARC / écritures (le SSD est-il martelé ?)

cr0x@server:~$ grep -E "l2arc_write|l2arc_feed" /proc/spl/kstat/zfs/arcstats | head
l2arc_write_bytes                        4    982374982374
l2arc_write_issued                        4    1293847
l2arc_feed_calls                          4    9182
l2arc_feed_bytes                          4    982374982374

Ce que cela signifie : L2ARC a écrit ~982GB (depuis le boot/chargement du module). Si ce nombre monte rapidement, l’endurance et le throttling deviennent des préoccupations réelles.
Décision : Si le taux d’alimentation est énorme et que le taux de hits est faible, désactivez L2ARC ou réduisez l’agressivité du feed (là où des tunables existent et sont testés).

Tâche 10 : Vérifier la santé et l’usure du SSD (réalité des SSD SATA)

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep "Model Number|Power_On_Hours|Media_Wearout|Percentage Used|Total_LBAs_Written|Reallocated|CRC_Error"
Model Number:                       Samsung SSD 870 EVO 1TB
Power_On_Hours:                    12890
Percentage Used:                   12%
Total_LBAs_Written:                1823749821
Reallocated_Sector_Ct:             0
UDMA_CRC_Error_Count:              0

Ce que cela signifie : « Percentage Used » est un indicateur d’usure ; les erreurs CRC peuvent indiquer des problèmes de câblage/contrôleur.
Décision : Si l’usure augmente rapidement ou que des CRC apparaissent, traitez le périphérique cache comme un composant sous stress et planifiez un remplacement ou un changement de stratégie.

Tâche 11 : Confirmer la vitesse du lien SATA et le mode négocié (éviter l’embarras 1.5Gbps)

cr0x@server:~$ sudo smartctl -a /dev/sdg | egrep "SATA Version|SATA.*current"
SATA Version is:  SATA 3.3, 6.0 Gb/s (current: 6.0 Gb/s)

Ce que cela signifie : Le SSD fonctionne à 6.0 Gb/s. S’il affiche 1.5 ou 3.0, votre contrôleur/câble/backplane peut le limiter.
Décision : Corrigez le lien avant de juger les performances L2ARC.

Tâche 12 : Mesurer si les lectures passent des HDD au L2ARC (avant/après)

cr0x@server:~$ zpool iostat -v tank 2 2
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.3T  7.10T    420    150  38.0M  11.5M
  raidz2-0                  12.3T  7.10T    420    150  38.0M  11.5M
    sda                         -      -     70     26   6.0M   2.0M
    sdb                         -      -     71     25   6.1M   1.9M
    sdc                         -      -     70     26   6.0M   2.0M
    sdd                         -      -     69     25   5.9M   1.9M
    sde                         -      -     70     24   6.0M   1.8M
    sdf                         -      -     70     24   6.0M   1.8M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Si votre charge est similaire, la baisse des lectures HDD de ~980 ops à ~420 ops suggère que les hits cache ont augmenté (ARC et/ou L2ARC).
Décision : Corrélez avec la latence applicative. Si les utilisateurs le ressentent, gardez ; sinon, ne déclarez pas la victoire seulement d’après les compteurs de stockage.

Tâche 13 : Vérifier les propriétés de dataset qui affectent le comportement du cache

cr0x@server:~$ zfs get -o name,property,value -s local,default recordsize,primarycache,secondarycache,compression tank/vmstore
NAME          PROPERTY        VALUE
tank/vmstore  recordsize      128K
tank/vmstore  primarycache    all
tank/vmstore  secondarycache  all
tank/vmstore  compression     lz4

Ce que cela signifie : secondarycache=all permet à L2ARC de mettre en cache données et métadonnées (selon la politique ZFS).
Décision : Pour certaines charges, régler secondarycache=metadata peut réduire les écritures SSD tout en gardant la réactivité pour les recherches de fichiers.

Tâche 14 : Restreindre ce qui va dans le L2ARC pour un dataset bruyant

cr0x@server:~$ sudo zfs set secondarycache=metadata tank/backups
cr0x@server:~$ zfs get -o name,property,value secondarycache tank/backups
NAME          PROPERTY        VALUE
tank/backups  secondarycache  metadata

Ce que cela signifie : Le dataset backups arrêtera de polluer le L2ARC avec des données bulk ; les métadonnées peuvent toujours être mises en cache.
Décision : Utilisez ceci quand un dataset « froid » charrie le L2ARC et évince les blocs utiles pour des workloads interactifs.

Tâche 15 : Retirer un périphérique L2ARC (pour rollback)

cr0x@server:~$ sudo zpool remove tank ata-SAMSUNG_SSD_870_EVO_1TB_S6PNNX0R123456A
cr0x@server:~$ zpool status tank
  pool: tank
 state: ONLINE
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0
            sdf     ONLINE       0     0     0

Ce que cela signifie : Le périphérique cache a été retiré proprement.
Décision : Si L2ARC n’a pas amélioré la latence pendant la fenêtre de charge réelle, retirez-le et arrêtez de payer la taxe opérationnelle.

Trois mini-histoires d’entreprise tirées du réel

1) Incident causé par une mauvaise hypothèse : « SSD cache = tout plus rapide »

Une entreprise de taille moyenne exploitait un cluster NFS sur ZFS pour répertoires personnels et artefacts CI. La capacité était un RAIDZ2 de gros HDD.
Les développeurs se plaignaient de « lenteurs aléatoires », surtout pendant de gros builds et quand les runners récupéraient des artefacts.

Un ingénieur bien intentionné ajouta un SSD SATA grand public comme L2ARC sur chaque nœud. Personne ne mesura ; ils attendaient les louanges.
Ce qu’ils obtinrent fut un incident au ralenti : après quelques jours, les SSD commencèrent à montrer une latence accrue et des réinitialisations occasionnelles.
Les builds ralentirent, et les clients NFS commencèrent à timeouter par intermittence, ce qui ressemblait à un problème réseau jusqu’à ce que ce ne le soit plus.

La mauvaise hypothèse était que la charge était cacheable en lecture. Ce n’était pas le cas. Les pulls d’artefacts étaient souvent des lectures uniques ; les builds écrivaient constamment de nouveaux outputs ;
l’ensemble « chaud » changeait toutes les heures. L2ARC était fortement alimenté avec des blocs jamais relus, transformant le SSD en puits d’écritures.

La correction fut peu glamour : retirer le L2ARC, ajouter de la RAM et séparer le store d’artefacts sur un ensemble mirror vdev dimensionné pour les IOPS, pas la capacité.
L’équipe mit aussi secondarycache=metadata pour le dataset de sauvegarde qui polluait l’ARC/L2ARC pendant les jobs nocturnes.

Ensuite, la performance s’améliora de la seule manière qui compte : moins d’alertes, moins de plaintes, et des graphes qui cessèrent de ressembler à de la sismologie.

2) Optimisation qui se retourna contre eux : « On va rendre L2ARC énorme »

Une plateforme analytique interne tournait sur ZFS. L’équipe stockage avait une RAM respectable et remarqua des misses ARC pendant la ruée matinale des dashboards.
Ils ajoutèrent une paire de grands SSD SATA comme L2ARC et décidèrent de « faire gros » car les SSD étaient bon marché par Go.

Les chiffres initiaux semblaient prometteurs : la taille L2ARC monta dans les térabytes et les comptes de hits augmentèrent. Mais la latence utilisateur ne s’améliora pas beaucoup.
Pire, des arrêts périodiques apparurent — de courtes pauses vives qui ressemblaient à des soubresauts applicatifs jusqu’à ce qu’on les corrèle avec les métriques stockage.

Le retour de bâton vint de l’overhead mémoire et du churn. La machine portait désormais une empreinte d’index L2ARC beaucoup plus grande en RAM, réduisant l’ARC effectif.
Sous charge de pointe, l’éviction ARC augmenta, l’alimentation L2ARC augmenta, et les SSD SATA atteignirent leurs limites d’écriture soutenue.
Le tier de cache commença à se comporter comme un embranchement congestionné : tout ralentissait parce que trop de choses essayaient d’entrer.

L’équipe corrigea en réduisant les ambitions : ils limitèrent les datasets pouvant utiliser L2ARC (encore une fois, secondarycache fut le levier),
et cessèrent de traiter L2ARC comme un substitut bon marché à une meilleure disposition de vdevs.
Plus tard, ils migrèrent les datasets de dashboard lecteurs-intensifs vers des mirrors NVMe et gardèrent les SATA pour des rôles moins sensibles à la latence.

La leçon fut douloureuse mais utile : « cache plus grand » n’est pas une stratégie de performance à moins que votre charge soit réellement cache-friendly et que votre système ait le budget mémoire pour l’indexer.

3) Pratique ennuyeuse mais correcte qui a sauvé la mise : mesures de base et rollback

Une entreprise réglementée avait une plateforme ZFS supportant plusieurs services internes. Ils voulaient améliorer la lecture pour un datastore VM sur mirrors HDD.
Les délais d’achat étaient lents, donc l’ingénieur stockage proposa un L2ARC SSD SATA comme boost temporaire.

Avant toute modification, ils firent trois choses ennuyeuses : capturer la latence de base pendant le pic, enregistrer les stats ARC/L2ARC (pas encore de L2ARC),
et écrire un plan de rollback incluant la commande exacte zpool remove et une fenêtre de changement.
Ils vérifièrent aussi les attributs SMART et confirmèrent la vitesse SATA négociée sur le contrôleur prévu.

Le changement se passa proprement. Pendant deux semaines, les métriques montrèrent un recul clair : les ops de lecture HDD baissèrent pendant les tempêtes de démarrage, et la latence p95 applicative s’améliora modestement mais de façon constante.
Puis un bug firmware du modèle de SSD surgit (pas catastrophique, juste agaçant) et le périphérique disparaissait occasionnellement sous forte charge d’écriture.

Parce qu’ils avaient des baselines, ils purent quantifier la régression, désactiver L2ARC rapidement et revenir à l’état connu sans débat ni concours de blâme.
Plus tard ils remplacèrent le modèle de SSD par un modèle ayant un meilleur comportement soutenu, et réintroduisirent L2ARC en toute confiance.

Personne n’a reçu de trophée pour la « meilleure hygiène opérationnelle ». Mais personne n’a été dérangé la nuit non plus, et c’est le vrai prix.

Erreurs courantes : symptômes → cause → correctif

1) Symptom : taux de hit L2ARC proche de zéro après des jours

Cause : La charge ne relit pas les blocs, ou les datasets ne sont pas éligibles au L2ARC à cause des réglages secondarycache, ou le cache est constamment pollué par des flux.

Correctif : Validez le comportement de relecture de la charge ; mettez secondarycache=metadata sur les datasets de streaming ; envisagez de retirer L2ARC et d’ajouter RAM ou vdevs à la place.

2) Symptom : le système semble plus lent après ajout de L2ARC

Cause : Pression mémoire (ARC réduit par l’overhead d’index L2ARC), plus des E/S SSD supplémentaires pour l’alimentation du cache.

Correctif : Ajoutez de la RAM ou réduisez les workloads concurrents ; limitez l’ARC correctement ; restreignez l’usage du L2ARC par dataset ; envisager un L2ARC plus petit ou pas de L2ARC.

3) Symptom : le périphérique SSD montre une usure élevée rapidement

Cause : Taux d’alimentation L2ARC élevé dû à un ARC churn ; endurance SATA grand public non dimensionnée pour cela.

Correctif : Choisissez un SSD d’endurance supérieure ; réduisez l’alimentation en restreignant les datasets ; priorisez la croissance ARC ; envisagez NVMe pour des performances soutenues si nécessaire.

4) Symptom : pauses I/O périodiques pendant les pointes

Cause : Throttling des SSD SATA ou contrôleur SATA saturé ; l’alimentation du cache concurrence les lectures ; comportement firmware du SSD sous écritures soutenues.

Correctif : Vérifiez le comportement en écriture soutenue ; confirmez la vitesse du lien ; répartissez le cache sur plusieurs appareils/contrôleurs ; choisissez des SSD avec écritures soutenues stables et PLP.

5) Symptom : excellents chiffres synthétiques, aucune amélioration réelle

Cause : Le benchmark tient dans l’ARC ou utilise un pattern cache-friendly différent de la production ; la fenêtre de mesure ignore la montée en chauffe et la localité d’accès réelle.

Correctif : Mesurez pendant le pic réel ; nettoyez les artefacts de test ; évaluez la latence end-to-end et la réduction des ops disque, pas seulement les compteurs de cache.

6) Symptom : après reboot, la performance est mauvaise « jusqu’à ce que ça aille mieux »

Cause : Montée en chauffe L2ARC ; le contenu du cache n’est pas immédiatement utile ou non reconstruit ; ARC à froid.

Correctif : Planifiez les reboots pendant les fenêtres de faible trafic ; réchauffez les caches en preloadant les datasets communs si c’est pratique ; ne jugez pas l’efficacité du L2ARC immédiatement après un reboot.

Listes de contrôle / plan étape par étape

Checklist de décision : devriez-vous ajouter un L2ARC SATA ?

1. La douleur est-elle surtout la latence de lecture ? Si non, arrêtez. L2ARC ne résoudra pas un goulot d’écriture.
2. Les disques sont-ils saturés pendant la fenêtre de douleur ? Si non, vous êtes peut-être limité par le CPU/réseau/app.
3. Le taux de miss ARC est-il significatif ? Si les hits ARC dominent déjà, L2ARC déplacera peu la mesure.
4. La charge relit-elle les données ? Si non, L2ARC devient une brûlure d’endurance.
5. Avez-vous de la marge RAM ? Si vous swappez, n’ajoutez pas de L2ARC.
6. Pouvez-vous mesurer avant/après ? Si non, vous faites du théâtre de performance.

Plan d’implémentation (sûr, réversible)

1. Enregistrez la baseline : zpool iostat, iostat -x, arcstat pendant le pic.
2. Choisissez le SSD : privilégiez endurance et écritures soutenues stables plutôt que le marketing.
3. Vérifiez le chemin matériel : bon contrôleur, 6.0 Gb/s négociés, refroidissement décent.
4. Ajoutez le L2ARC avec zpool add tank cache ....
5. Attendez la montée en chauffe sous charge réelle ; ne notez pas le résultat après 10 minutes.
6. Comparez : ops/latence disque et latence applicative p95/p99.
7. Si ça aide, restreignez les datasets bruyants avec secondarycache.
8. Si ça n’aide pas, retirez avec zpool remove et passez à autre chose.

Checklist opérationnelle (éviter les surprises)

• Surveillez l’usure SSD mensuellement (SMART).
• Alertez sur disparition du périphérique cache ou erreurs de lien (CRC).
• Documentez que le cache est jetable pour éviter la panique pendant le remplacement.
• Retestez les performances après des changements majeurs de charge (nouvelle version d’app, nouveaux patterns de requêtes, nouvelle flotte VM).

FAQ

1) Est-ce que L2ARC accélère les écritures ?

Non. L2ARC est un cache de lecture. Pour la latence d’écriture synchrone regardez le SLOG, et même là il s’agit de journalisation, pas d’accélération de toutes les écritures.

2) Dois-je ajouter L2ARC avant d’ajouter de la RAM ?

Presque jamais. La RAM augmente l’ARC sans ajouter la latence du périphérique, des écritures d’alimentation ou des surfaces de panne supplémentaires. Si vous pouvez ajouter de la RAM, faites-le d’abord.

3) Un SSD SATA grand public est-il « suffisant » pour L2ARC ?

Parfois. Si votre feed L2ARC est modeste et que votre charge est très orientée lecture avec de vraies relectures, cela peut être acceptable. Si le feed est important, les SSD grand public s’usent et se throttlent.

4) Comment savoir si ma charge relit des données ?

Observez si les hits cache augmentent dans le temps et si les opérations de lecture HDD diminuent alors que la charge reste similaire. Si L2ARC n’arrête pas d’écrire mais que les hits restent faibles, ce n’est pas favorable aux relectures.

5) L2ARC persiste-t-il après un reboot ?

Le contenu SSD peut rester, mais l’utilisabilité dépend de si ZFS reconstruit l’index et de la configuration plateforme. Pratiquement, prévoyez une période de montée en chauffe après reboot.

6) Dois-je mirrorer les périphériques L2ARC ?

Généralement non. L2ARC est jetable ; si le périphérique meurt, vous perdez du cache, pas des données. Si la perte de cache provoque une dégradation de performance inacceptable, la vraie solution est plus d’ARC ou du stockage primaire plus rapide.

7) Pourquoi mon L2ARC montre de l’activité mais les utilisateurs ne ressentent rien ?

Vous pouvez cibler des métadonnées ou de petits blocs alors que la vraie douleur est ailleurs (CPU, réseau, écritures synchrones), ou vos hits portent sur des lectures non critiques. Mesurez la latence applicative et les ops disque, pas seulement les compteurs de cache.

8) Puis-je restreindre quels datasets utilisent le L2ARC ?

Oui. Utilisez secondarycache par dataset (par exemple metadata pour des datasets de streaming/sauvegarde) pour éviter de polluer le L2ARC avec des données froides en masse.

9) SSD SATA ou NVMe pour L2ARC ?

NVMe l’emporte sur la latence et le parallélisme. Le SATA peut aider quand vous remplacez des misses HDD par des hits SSD « suffisants » à moindre coût, et que votre charge n’est pas ultra-sensible à la latence.

10) Quelle est l’alternative au L2ARC pour les workloads de petits fichiers ?

Un special vdev (avec redondance) peut stocker métadonnées et petits blocs sur SSD, souvent en fournissant des gains supérieurs à L2ARC pour les workloads dominés par les métadonnées. Mais ce n’est pas jetable ; concevez-le comme du stockage réel.

Prochaines étapes concrètes que vous pouvez faire aujourd’hui

1. Exécutez la procédure de diagnostic rapide pendant le pic et notez si vous êtes limité par la lecture, l’écriture, le CPU ou la mémoire.
2. Capturez des baselines : iostat -x, zpool iostat -v, arcstat pendant au moins 10 minutes durant la fenêtre problématique.
3. Si vous êtes candidat, ajoutez un SSD SATA L2ARC avec un plan de rollback clair et une fenêtre de mesure suffisamment longue pour la montée en chauffe.
4. Rendez-le ennuyeux : monitorisez l’usure SMART, alertez sur les erreurs de périphérique, et gardez les réglages de cache des datasets intentionnels.
5. Si L2ARC ne réduit pas la latence utilisateur, retirez-le. Investissez le temps et l’argent dans l’ARC (RAM), le design des vdevs, ou migrez le dataset chaud vers un stockage plus rapide.

Le meilleur résultat n’est pas « on a ajouté un cache ». C’est « on a prouvé quel était le goulot, on l’a corrigé, et maintenant personne ne parle de stockage en réunion quotidienne ».