ZFS vs Storage Spaces : pourquoi « facile » peut devenir « opaque »

Ce que signifie « opaque » en production

« Opaque » n’est pas une injure. C’est une propriété : le système masque des états importants derrière des abstractions conviviales, et quand la performance
ou la fiabilité partent en vrille, vous ne pouvez pas répondre rapidement à :

• Quels périphériques physiques sont lents maintenant ?
• La redondance est-elle actuellement dégradée ?
• Le système répare-t-il des données, remodèle-t-il la disposition ou bride-t-il les écritures ?
• Le problème vient-il de la capacité, de la fragmentation, de la pression sur les métadonnées, des ratés de cache, ou d’un seul disque mourant ?

Les abstractions sont utiles. Elles permettent à un généraliste de déployer du stockage sans devenir archéologue de systèmes de fichiers. Mais l’abstraction est un
compromis : vous gagnez en facilité et perdez en immédiateté. Si votre plateforme a déjà une forte culture opérationnelle—SLO clairs, télémétrie cohérente, réponse aux
incidents pratiquée—vous pouvez survivre avec quelque chose de plus opaque. Sinon, l’abstraction vous couvrira les yeux pendant que vous courrez vers la falaise.

J’ai un biais pour les systèmes où les preuves sont locales, structurées et difficiles à falsifier. ZFS le fait bien. Storage Spaces peut aussi le faire, mais en pratique on
rencontre plus souvent des raisonnements du type « ça devrait marcher » plutôt que « voici la chaîne de preuve ».

Philosophies différentes : vérité auto-descriptive vs abstraction gérée

ZFS : le système de fichiers qui traite le stockage comme une base de données

ZFS n’est pas juste « un RAID et un système de fichiers ». C’est une pile de stockage construite autour des checksums end-to-end, de la sémantique copy-on-write, et
d’un modèle cohérent de vérité : les blocs de données et les blocs de métadonnées se référencent mutuellement de façon à rendre la corruption détectable et,
avec de la redondance, réparable.

Opérationnellement, ZFS tend à vous récompenser lorsque vous apprenez son vocabulaire : vdevs, pools, datasets, snapshots, ARC, transaction groups,
scrubs, resilvers. Une fois que vous connaissez les noms, les actions se comportent de façon cohérente. Le système est opinionné et en grande partie honnête. Quand
il est en colère, il vous dit généralement pourquoi—parfois rudement, mais clairement.

Storage Spaces : l’état d’esprit « tissu de stockage »

Storage Spaces est une couche de virtualisation de stockage Windows : vous agrégez des disques physiques en pools, créez des disques virtuels avec résilience (miroir, parité),
puis formatez des volumes dessus. Dans l’univers Storage Spaces Direct (S2D), vous étendez cela sur plusieurs nœuds avec clustering.

Les forces sont évidentes dans les environnements d’entreprise :

• Il s’intègre aux outils de gestion Windows et aux modèles d’identité.
• Il est « cliquable » et scriptable avec PowerShell.
• Il s’intègre au clustering et aux fonctionnalités de Windows Server.

La faiblesse devient évidente dès qu’on est en on-call : la couche de stockage devient une expérience médiée. Quand la parité est lente,
quand un disque est marginal, quand le cache write-back se comporte mal, les couches « utiles » du système peuvent rendre l’analyse de la cause racine
aussi frustrante que de discuter avec un concierge sur l’endroit où il a garé votre voiture.

Une citation à garder au mur, car elle s’applique aux deux piles : « L’espoir n’est pas une stratégie. » — General Gordon R. Sullivan.

Blague n°1 : Le stockage, c’est comme un tableur partagé—tout le monde lui fait confiance jusqu’à ce que les formules renvoient « #REF! » en fin de trimestre.

Faits et historique qui comptent encore

Quelques points de contexte concrets—parce que le « pourquoi » se cache souvent dans le « quand » :

1. ZFS est né chez Sun comme partie de Solaris, conçu à une époque où les contrôleurs RAID disaient parfois des mensonges et où le bit-rot n’était pas théorique.
2. Les checksums end-to-end étaient une motivation centrale de ZFS : le système suppose que les disques, câbles et contrôleurs peuvent corrompre les données silencieusement.
3. ZFS a popularisé le copy-on-write pour le stockage général, permettant des snapshots peu coûteux et un état disque cohérent après crashs.
4. « RAID-Z » fut la réponse de ZFS au problème du write hole dans les implémentations classiques RAID-5/6.
5. Storage Spaces est arrivé avec Windows 8 / Server 2012 comme tentative de Microsoft pour fournir du stockage poolé sans RAID fournisseur.
6. Storage Spaces Direct (S2D) a ensuite étendu le modèle en conception clusterisée hyperconvergée pour Windows Server.
7. L’intégration ReFS est devenue un élément clé de l’histoire de stockage Microsoft, avec integrity streams et résilience des métadonnées (mais le comportement dépend de la configuration).
8. Les deux écosystèmes ont tiré des leçons douloureuses sur le caching : le write-back caching peut sauver la performance et aussi amplifier les modes de défaillance lorsqu’il est mal dimensionné ou non protégé.

Ce ne sont pas des anecdotes. Elles expliquent pourquoi ZFS est obsédé par les signaux de correction (checksums, scrubs) et pourquoi Storage Spaces suppose souvent que vous voulez
une politique de stockage qui « fonctionne juste » jusqu’à ce que ce ne soit plus le cas.

À quoi ressemblent les pannes : ZFS vs Storage Spaces

Forme de panne 1 : corruption latente et « on a restauré des ordures »

Le mouvement signature de ZFS est de détecter la corruption pendant les lectures et pendant les scrubs. S’il y a de la redondance, ZFS peut réparer à partir d’une copie saine.
Ce n’est pas de la magie ; c’est des checksums cohérents et de la redondance au bon niveau. Le gain opérationnel est que vous pouvez prouver l’intégrité, pas seulement la supposer.

Storage Spaces peut offrir des fonctions d’intégrité selon le système de fichiers (ReFS) et les réglages. Mais dans de nombreuses déploiements, l’intégrité est
un après-pensée. Vous verrez « disque en bonne santé » alors que la corruption au niveau applicatif ronge tranquillement les données parce que la pile n’a pas été
configurée pour détecter cela de bout en bout.

Forme de panne 2 : comportement de reconstruction et longue traîne de douleur

Le resilvering ZFS est logique : il reconstruit seulement les blocs alloués (pour certaines topologies), pas nécessairement le disque entier. Cela peut être un
avantage opérationnel massif quand les pools sont grands mais en grande partie vides. La longue traîne est qu’un pool fragmenté ou une forte pression sur les métadonnées
peut rendre les resilvers lents et perturbateurs.

Les réparations Storage Spaces dépendent de la disposition et de si vous êtes sur Storage Spaces traditionnel ou S2D. Dans les configurations parité particulièrement,
les réparations peuvent être pénibles, et le système peut prioriser la « correction » d’une manière qui relègue votre charge de production en bruit de fond. Ce qui est effrayant,
c’est que le travail de réparation est parfois moins évident pour les opérateurs à moins de connaître les bons cmdlets et compteurs.

Forme de panne 3 : falaises de performance

ZFS a des falaises prévisibles :

• Mauvaise concordance de recordsize et petites écritures aléatoires peuvent nuire.
• Quiproquos sur le SLOG peuvent créer des dispositifs placebo ou de vrais goulots d’étranglement.
• Pression ARC se manifestera par des ratés de cache et une amplification d’I/O.
• Pool presque plein est un classique : la fragmentation et le coût d’allocation montent.

Storage Spaces a d’autres falaises :

• Pénalité d’écriture en parité est réelle, et « c’est juste de la parité » devient « pourquoi tout est 10x plus lent ».
• Thin provisioning peut se transformer en arrêt brutal lorsque la capacité physique est épuisée.
• Tiering et cache peuvent être brillants dans les benchmarks et étranges en production lorsque le working set change.
• Tâches en arrière-plan (réparation, optimisation, rebalance) peuvent voler de la performance sans alarmes utilisateur évidentes.

Forme de panne 4 : le facteur humain—ce que le système vous incite à ignorer

ZFS vous encourage à regarder zpool status, les scrubs planifiés et les compteurs d’erreurs. Storage Spaces vous encourage à regarder « HealthStatus: Healthy » et à faire
confiance à l’abstraction. Cela va tant que l’abstraction ne synthétise pas le détail unique dont vous aviez besoin : quel disque présente des délais d’attente, quel boîtier
bascule, quelle tranche de capacité est sur-allouée.

Tâches pratiques pour l’opérateur (commandes, sorties, décisions)

Ce ne sont pas des commandes « jouets ». Ce sont celles que vous exécutez pendant un incident et à nouveau pendant le postmortem, lorsque vous décidez
si la plateforme est digne de confiance ou simplement poliment silencieuse.

Task 1 (ZFS) : Vérifier la santé du pool et le comptage d’erreurs

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: ONLINE
status: One or more devices has experienced an error resulting in data corruption.
action: Restore the file in question if possible.
  scan: scrub repaired 0B in 06:21:14 with 1 errors on Wed Dec  4 02:18:10 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        ONLINE       0     0     0
          raidz2-0                  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d4  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d5  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d6  ONLINE       0     0     0
            wwn-0x5000c500a1b2c3d7  ONLINE       0     0     1

errors: Permanent errors have been detected in the following files:

        tank/data/app.db

Ce que cela signifie : Le pool est en ligne, mais une erreur de checksum a été détectée et localisée sur un fichier. Ce n’est pas « correct ».
C’est une histoire : un secteur défectueux, un câble, un contrôleur, ou la mémoire. ZFS l’a détecté ; maintenant vous devez réagir.

Décision : Restaurer ou reconstruire le fichier affecté à partir d’une source connue saine, puis enquêter sur le périphérique avec des erreurs CKSUM.
Si les erreurs se répètent, remplacez ce chemin disque (disque, câble, port HBA) même si SMART semble « OK ».

Task 2 (ZFS) : Confirmer le calendrier des scrubs et le résultat du dernier scrub

cr0x@server:~$ zpool status tank | sed -n '1,15p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 06:21:14 with 0 errors on Wed Dec 18 02:11:05 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
errors: No known data errors

Ce que cela signifie : Le scrub s’est terminé, n’a rien réparé, n’a trouvé aucune erreur. C’est votre preuve périodique d’intégrité.

Décision : Si vous ne voyez pas des scrubs s’achever régulièrement, planifiez-les. Si les scrubs prennent de plus en plus de temps, considérez cela comme
un signal capacité/performance (fragmentation, disques lents, disques SMR, ou changement de charge).

Task 3 (ZFS) : Identifier la latence I/O au niveau du vdev

cr0x@server:~$ zpool iostat -v tank 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
tank                        12.1T  7.8T     90    420   12.3M  55.4M
  raidz2-0                  12.1T  7.8T     90    420   12.3M  55.4M
    wwn-...c3d4                 -      -     12     58  1.6M   7.6M
    wwn-...c3d5                 -      -     11     54  1.5M   7.1M
    wwn-...c3d6                 -      -     12     57  1.6M   7.4M
    wwn-...c3d7                 -      -     55    197  6.3M  26.0M
--------------------------  -----  -----  -----  -----  -----  -----

Ce que cela signifie : Un disque effectue une quantité disproportionnée de travail. Parfois c’est normal (blocs chauds, un frère lent, ou une défaillance partielle poussant
les lectures ailleurs). C’est aussi ainsi que vous repérez un disque qui « fonctionne » mais qui ne suit pas.

Décision : Corrélez avec SMART et les logs du noyau. Si un périphérique affiche systématiquement un comportement différent, remplacez-le préventivement ou au minimum changez-le
de baie/câble pour isoler le chemin.

Task 4 (ZFS) : Vérifier le comportement de l’ARC (pression mémoire vs taux de cache)

cr0x@server:~$ arcstat 1 5
    time  read  miss  miss%  dmis  dm%  pmis  pm%  mmis  mm%  arcsz     c
12:10:01  8120   610      7   210   34   400   66     0    0   58G   64G
12:10:02  7901   645      8   240   37   405   63     0    0   58G   64G
12:10:03  8012   702      9   260   37   442   63     0    0   58G   64G
12:10:04  7998   690      9   250   36   440   64     0    0   58G   64G
12:10:05  8105   720      9   270   38   450   62     0    0   58G   64G

Ce que cela signifie : Un taux de miss ~9% n’est pas intrinsèquement mauvais, mais si la latence est élevée et que les misses augmentent, les disques travaillent plus.
« arcsz » proche de « c » signifie que l’ARC est à la taille cible ; il peut néanmoins y avoir de la pression mémoire ailleurs.

Décision : Si les misses explosent sous charge, ajoutez de la RAM, réduisez le working set, ajustez recordsize/compression, ou envisagez des vdevs spéciaux / devices
pour métadonnées avec précaution. N’ajoutez pas L2ARC par réflexe sans connaître vos schémas de lecture.

Task 5 (ZFS) : Confirmer les propriétés du dataset qui influencent la performance

cr0x@server:~$ zfs get -o name,property,value -s local recordsize,compression,atime,logbias tank/data
NAME       PROPERTY     VALUE
tank/data  atime        off
tank/data  compression  zstd
tank/data  logbias      latency
tank/data  recordsize   128K

Ce que cela signifie : Ces paramètres façonnent les schémas d’I/O. recordsize impacte l’amplification ; la compression peut réduire l’I/O ;
logbias affecte la gestion des écritures synchrones dans certains cas.

Décision : Si ce dataset est une base de données avec des pages 16K, un recordsize à 128K peut être inadapté. Changez-le avant la prochaine grosse charge,
et validez. Vous gérez la physique, pas des impressions.

Task 6 (ZFS) : Surveiller un pool qui se remplit trop

cr0x@server:~$ zfs list -o name,used,avail,refer,mountpoint tank
NAME   USED  AVAIL  REFER  MOUNTPOINT
tank   12.1T 7.8T   128K   /tank

Ce que cela signifie : La capacité semble correcte pour l’instant. Mais le seuil opérationnel réel n’est pas « 100% plein ». Pour beaucoup de pools,
la performance et le comportement d’allocation se dégradent bien avant, surtout avec RAIDZ et des espaces libres fragmentés.

Décision : Considérez ~80% comme le début de conversations sérieuses, et ~85–90% comme « arrêter d’ajouter des données à moins d’ajouter aussi des vdevs ».
Définissez des quotas/réservations pour les locataires bruyants.

Task 7 (ZFS) : Remplacer proprement un disque et vérifier la progression du resilver

cr0x@server:~$ zpool replace tank wwn-0x5000c500a1b2c3d7 /dev/disk/by-id/wwn-0x5000c500a1b2c3ff
cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Thu Dec 19 03:14:22 2025
        1.27T scanned at 1.12G/s, 412G issued at 362M/s, 8.41T total
        412G resilvered, 4.78% done, 06:23:10 to go
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz2-0                  DEGRADED     0     0     0
            wwn-...c3d4             ONLINE       0     0     0
            wwn-...c3d5             ONLINE       0     0     0
            wwn-...c3d6             ONLINE       0     0     0
            replacing-3             DEGRADED     0     0     0
              wwn-...c3d7           OFFLINE      0     0     0
              wwn-...c3ff           ONLINE       0     0     0

Ce que cela signifie : ZFS est en cours de resilver. La sortie vous donne une ETA et un débit. La topologie montre « replacing » qui est exactement
l’état attendu en cours d’opération.

Décision : Si le taux de resilver s’effondre ou si les erreurs augmentent, cessez de traiter cela comme routinier. Enquêtez sur les erreurs du contrôleur,
le câblage et la charge. Envisagez de programmer les jobs lourds en dehors des fenêtres de resilver.

Task 8 (Linux + ZFS) : Prouver que le noyau voit des erreurs disque (pas seulement ZFS)

cr0x@server:~$ dmesg -T | egrep -i 'reset|i/o error|timeout|sense key' | tail -n 6
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] tag#231 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] Sense Key : Medium Error [current]
[Thu Dec 19 03:20:11 2025] sd 6:0:5:0: [sdf] Add. Sense: Unrecovered read error
[Thu Dec 19 03:20:11 2025] blk_update_request: I/O error, dev sdf, sector 184467440
[Thu Dec 19 03:20:12 2025] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[Thu Dec 19 03:20:13 2025] ata7: hard resetting link

Ce que cela signifie : L’OS voit des medium errors et des resets de lien. Ce n’est plus « ZFS qui chipote ». C’est du matériel qui se comporte mal.

Décision : Remplacez le composant suspect. Si cela se répète sur différents disques du même chemin, remplacez le chemin (HBA, backplane, expander, câble).
Ne « surveillez » pas un disque qui renvoie des medium errors pendant un resilver.

Task 9 (Storage Spaces) : Inspecter les disques physiques et le type de média

cr0x@server:~$ powershell -NoProfile -Command "Get-PhysicalDisk | Select FriendlyName,SerialNumber,MediaType,HealthStatus,OperationalStatus,Size | Format-Table -Auto"
FriendlyName SerialNumber MediaType HealthStatus OperationalStatus Size
------------ ------------ --------- ------------ ----------------- ----
PD01         Z4A0...      HDD       Healthy      OK                7.28 TB
PD02         Z4A1...      HDD       Healthy      OK                7.28 TB
PD03         Z4A2...      HDD       Warning      OK                7.28 TB
PD04         Z4A3...      HDD       Healthy      OK                7.28 TB

Ce que cela signifie : « Warning » sur un disque physique est votre alarme précoce. Storage Spaces continue souvent de fonctionner pendant que
le disque se dégrade—jusqu’à ce que ce ne soit plus le cas.

Décision : Corrélez avec les outils SMART/fournisseur et les journaux d’événements. Si le disque est en « Warning », planifiez son remplacement maintenant, pas
après que le disque virtuel passe en « Degraded ».

Task 10 (Storage Spaces) : Vérifier la santé et la résilience du disque virtuel

cr0x@server:~$ powershell -NoProfile -Command "Get-VirtualDisk | Select FriendlyName,ResiliencySettingName,HealthStatus,OperationalStatus,Size,FootprintOnPool | Format-Table -Auto"
FriendlyName ResiliencySettingName HealthStatus OperationalStatus Size    FootprintOnPool
------------ --------------------- ------------ ----------------- ----    ---------------
VD-Data      Parity                Healthy      OK                40 TB   60 TB
VD-VMs       Mirror                Healthy      OK                12 TB   24 TB

Ce que cela signifie : L’empreinte en parité est plus grande que la taille logique à cause de la disposition et du surcoût de parité. Cela indique aussi
une amplification d’écriture et des coûts de reconstruction. Le miroir est plus prévisible opérationnellement.

Décision : Si votre charge est lourde en écritures ou sensible à la latence, la parité est une taxe que vous paierez quotidiennement. Placez les charges chaudes
sur du mirror ou du tiered mirror, et réservez la parité pour des données plus froides avec des attentes claires.

Task 11 (Storage Spaces) : Vérifier l’espace libre du pool vs risque de thin provisioning

cr0x@server:~$ powershell -NoProfile -Command "Get-StoragePool -IsPrimordial $false | Select FriendlyName,HealthStatus,Size,AllocatedSize,FreeSpace | Format-List"
FriendlyName  : Pool01
HealthStatus  : Healthy
Size          : 58.2 TB
AllocatedSize : 54.9 TB
FreeSpace     : 3.3 TB

Ce que cela signifie : Il ne reste qu’environ 3.3 TB. Si vous avez des disques virtuels thin-provisionnés qui grossissent, vous pouvez atteindre un arrêt brutal.
Windows essaiera de vous prévenir. La production essaiera de l’ignorer.

Décision : Mettez en place des alertes sur FreeSpace, et imposez des garde-fous : soit interdisez le thin provisioning pour les systèmes critiques, soit gardez une
marge réelle avec une politique (p.ex. ne jamais descendre sous 15–20%).

Task 12 (Storage Spaces) : Identifier des jobs de réparation/optimisation en cours qui volent la performance

cr0x@server:~$ powershell -NoProfile -Command "Get-StorageJob | Select Name,JobState,PercentComplete,BytesProcessed,TimeRemaining | Format-Table -Auto"
Name                      JobState  PercentComplete BytesProcessed TimeRemaining
----                      --------  --------------- ------------- -------------
Repair Virtual Disk       Running   17              3.1 TB         05:12:33
Optimize Storage Pool     Running   42              9.8 TB         02:01:10

Ce que cela signifie : Des travaux en arrière-plan sont actifs. C’est souvent la raison cachée pour laquelle « le stockage est devenu lent ». Les jobs sont légitimes—mais
ils sont en concurrence avec votre charge.

Décision : Si c’est en production, planifiez ces jobs ou bridez-les lorsque c’est possible. Si des réparations s’exécutent fréquemment, arrêtez-vous et demandez pourquoi :
disques défaillants, connexions instables, ou mauvaise configuration.

Task 13 (Storage Spaces) : Cartographier un disque virtuel vers les disques physiques sous-jacents

cr0x@server:~$ powershell -NoProfile -Command "$vd=Get-VirtualDisk -FriendlyName 'VD-Data'; Get-PhysicalDisk -VirtualDisk $vd | Select FriendlyName,HealthStatus,OperationalStatus,Size | Format-Table -Auto"
FriendlyName HealthStatus OperationalStatus Size
------------ ------------ ----------------- ----
PD01         Healthy      OK                7.28 TB
PD02         Healthy      OK                7.28 TB
PD03         Warning      OK                7.28 TB
PD04         Healthy      OK                7.28 TB

Ce que cela signifie : Vous pouvez rattacher l’abstraction aux disques réels. C’est ainsi que vous évitez de remplacer le mauvais disque dans le mauvais châssis
pendant que tout le monde regarde.

Décision : Remplacez le disque en « Warning » et confirmez que le job de réparation démarre. Si plusieurs disques sont en « Warning », supposez un domaine de faute partagé
(boîtier/backplane/firmware).

Task 14 (Storage Spaces / Windows) : Lire le journal des événements pour des signaux spécifiques au stockage

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -LogName System -MaxEvents 30 | Where-Object {$_.ProviderName -match 'Disk|Stor|Microsoft-Windows-Storage'} | Select TimeCreated,ProviderName,Id,LevelDisplayName,Message | Format-Table -Wrap"
TimeCreated           ProviderName                         Id LevelDisplayName Message
----------           ------------                         -- ----------------  -------
12/19/2025 03:21:10  Microsoft-Windows-StorageSpaces-Driver 312 Error            Physical disk has encountered an error and may fail.
12/19/2025 03:21:14  Disk                                 153 Warning          The IO operation at logical block address was retried.
12/19/2025 03:22:01  storahci                             129 Warning          Reset to device, \Device\RaidPort0, was issued.

Ce que cela signifie : C’est l’équivalent Windows de la vérité dans dmesg. Les retries et resets de disque prédisent des problèmes plus graves.

Décision : Traitez les avertissements répétés de type 153/129 comme un incident matériel, pas un mystère logiciel. Vérifiez le firmware, le câblage,
les drivers du contrôleur et la stabilité de l’alimentation.

Blague n°2 : Un pool de stockage ressemble beaucoup à une réorganisation d’entreprise—tout est « plus résilient » jusqu’à ce que vous ayez à trouver qui possède le problème.

Trois mini-récits d’entreprise depuis le terrain

Mini-récit 1 : Un incident causé par une mauvaise hypothèse

Une société SaaS de taille moyenne exécutait des services de fichiers Windows pour des artefacts de build internes et quelques partages d’applications legacy. Ils
sont passés d’un RAID traditionnel à Storage Spaces parce que cela promettait une extension plus simple. La migration s’est bien passée, le pool était sain, et ils aimaient
l’idée du thin provisioning. « On ajoutera des disques quand il le faudra. »

La mauvaise hypothèse : croire que les pannes de thin provisioning sont douces. Elles ne le sont pas. Le thin provisioning est un accord avec le futur, et le futur ne signe
pas les SLA.

Sur un trimestre, quelques équipes ont augmenté la rétention d’artefacts. Quelques environnements de test ont commencé à déposer des jeux de données volumineux sur le partage
« temporairement ». L’espace libre du pool a lentement diminué. La surveillance existait, mais elle regardait l’espace libre du volume logique à l’intérieur du disque virtuel,
pas l’espace libre du pool de stockage en dessous. Le partage avait encore beaucoup d’espace logique, donc personne ne s’inquiétait.

Puis un job hebdomadaire a provoqué un pic de croissance, le pool a manqué de capacité physique, et les écritures ont commencé à échouer. Pas « lentes ». Des erreurs. Les
applications qui supposaient des sémantiques POSIX se sont mal comportées. Certaines ont réessayé agressivement. D’autres ont corrompu leurs propres métadonnées. Quelques-unes se sont
bloquées sur des I/O.

La correction n’a pas été héroïque. Ils ont libéré de l’espace, ajouté des disques et stabilisé le pool. La leçon : vous devez surveiller le pool, pas seulement le volume.
Et vous devez convenir d’une politique de marge que la direction ne pourra pas négocier en réunion.

Mini-récit 2 : Une optimisation qui s’est retournée contre eux

Une équipe plateforme de données utilisait ZFS sur Linux pour une charge mixte : blobs de type objet, extractions analytiques, et quelques instances PostgreSQL. Ils ont eu
des plaintes de performance, et quelqu’un a suggéré d’ajouter un NVMe rapide « en SLOG » parce qu’il avait lu un billet de blog une fois. Ils ont installé un NVMe grand public
bon marché et ont défini logbias=latency sur plusieurs datasets.

Pendant une semaine, les choses semblaient plus réactives. Pas partout, mais suffisamment pour se déclarer victorieux. Puis le NVMe a commencé à signaler des erreurs media,
suivies de timeouts. Le pool n’a pas explosé, mais la latence des écritures synchrones a grimpé en flèche. Les bases de données ont commencé à se bloquer. L’incident était
déroutant car les vdevs RAIDZ principaux étaient sains et iostat semblait « normal » à première vue.

Ils avaient optimisé la mauvaise chose et créé une dépendance fragile. Un SLOG ne compte que pour les écritures synchrones, et seulement si vous effectuez effectivement
des écritures sync. Pire : si vous ajoutez un SLOG qui ne peut pas garantir des écritures sûres contre une perte d’alimentation, vous pouvez transformer un crash ordonné en un cauchemar de récupération.

Le postmortem fut franc : ne pas coller un SLOG parce qu’on est nerveux. Mesurez votre taux d’écritures synchrones. Utilisez un device entreprise avec protection contre la
perte d’alimentation si vous le faites. Et souvenez-vous que tuner un dataset pour la latence peut pénaliser un autre dataset qui voulait du débit.

Le résultat à long terme fut positif. Ils ont retiré le NVMe grand public, ajusté recordsize pour les bases, activé la compression là où elle aidait, et ajouté de la RAM. Moins
excitant que « ajouter un disque cache magique », mais cela a fonctionné.

Mini-récit 3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Une société de services financiers exploitait une plateforme NFS sur ZFS pour des analytics internes. L’équipe n’était pas flashy. C’étaient des gens qui planifient des scrubs,
testent les restaurations, et refusent de faire tourner des pools à 92% de capacité. Les autres équipes les traitaient de paranoïaques. Ils appelaient ça « mardi ».

Un mois, une charge batch a commencé à échouer avec des erreurs de checksum pendant les lectures. ZFS a signalé une poignée de fichiers avec des erreurs permanentes.
Le pool est resté en ligne, mais la preuve était sans équivoque : certains blocs étaient mauvais. L’équipe n’a pas débattu pour savoir si ZFS « exagérait ». Ils l’ont traité
comme un incident d’intégrité des données.

Parce qu’ils exécutaient des scrubs réguliers, ils avaient une base saine connue et pouvaient affirmer, avec assurance, que la corruption était récente. Ils ont rapidement mappé
les erreurs à un chemin disque spécifique et trouvé des resets de lien répétés dans les logs du noyau. Ils ont remplacé le disque et le câble en même temps. Ils ont restauré
les fichiers affectés depuis des snapshots répliqués vers un second système.

Pas de drame, pas d’interruption prolongée. Le gain organisationnel était plus grand : ils pouvaient prouver que la plateforme détecte et contient la corruption. Cette preuve
importait plus que la performance brute.

La pratique ennuyeuse était une combinaison de discipline de scrub, réplication, et d’une culture de confiance dans les compteurs d’erreurs. Cela a sauvé la mise parce que cela
a réduit l’incertitude. L’incertitude est ce qui transforme les incidents en folklore.

Playbook de diagnostic rapide

L’objectif n’est pas de « collecter des données ». L’objectif est d’identifier quelle couche possède le goulot : workload, filesystem, gestionnaire de volume,
périphérique ou transport. Voici un ordre d’opérations pratique qui fonctionne sous pression.

Premier : confirmer s’il s’agit d’un travail de correction ou de charge utilisateur

• ZFS : zpool status (scrub/resilver en cours ? erreurs en hausse ?)
• Storage Spaces : Get-StorageJob (repair/optimize en cours ?)

Si une réparation en arrière-plan est active, votre « problème » de performance peut être une fonctionnalité de sécurité. Votre décision devient alors planification
et limitation—pas tourner des boutons au hasard.

Second : identifier si c’est une pression de capacité qui se déguise en latence

• ZFS : zfs list, vérifier le remplissage du pool et les symptômes de fragmentation
• Storage Spaces : Get-StoragePool FreeSpace ; valider les hypothèses de thin provisioning

Un système proche du plein n’est pas juste sans espace. Il est sans options. L’allocation devient coûteuse, les réparations plus lentes, et les files d’attente plus profondes.

Troisième : isoler le périphérique ou le chemin lent

• ZFS/Linux : zpool iostat -v + dmesg pour timeouts/resets
• Windows : journaux d’événements + états d’avertissement Get-PhysicalDisk

Si un disque est lent, votre « système de stockage » est otage de ce disque. Remplacez-le. Ne discutez pas avec lui.

Quatrième : valider les hypothèses de cache

• ZFS : statistiques ARC, comportement des écritures sync, présence et santé du SLOG
• Storage Spaces : paramètres de tiering, configuration du write-back cache, et si le cache est thrashé

Cinquième : aligner la forme d’I/O de la charge avec la disposition

Les écritures aléatoires sur des dispositions parité font mal. Les petits blocs sur de grands recordsize gaspillent de la bande passante. Les bases de données détestent les surprises.
Les partages de fichiers détestent les tempêtes de métadonnées. Si la charge a changé, le stockage « est soudain devenu pire » parce qu’il fait exactement ce que vous lui avez demandé—
juste pas ce que vous vouliez.

Erreurs courantes : symptôme → cause → correctif

1) « Tout est sain » mais les utilisateurs signalent des blocages

Symptôme : Les applis se bloquent sur I/O, mais les dashboards sont verts.

Cause : Réparations/optimisations en arrière-plan consommant des IOPS, ou un disque unique qui a des timeouts intermittents pendant que l’abstraction affiche toujours « Healthy ».

Correctif : Vérifiez Get-StorageJob / zpool status. Puis vérifiez les logs OS pour les timeouts. Remplacez le disque/chemin qui bascule.

2) Le disque virtuel en parité est « correct » mais les écritures sont douloureusement lentes

Symptôme : Bon débit en lecture, écritures aléatoires petites catastrophiques.

Cause : Pénalité d’écriture en parité et comportement read-modify-write ; cache mal dimensionné pour la charge ; tiering non aligné avec le pattern d’écriture.

Correctif : Utilisez le mirror pour les données lourdes en écritures, ou du tiering avec SSD et validez le taux de hit cache. Ne promettez pas la latence parité aux équipes base de données.

3) Le pool ZFS ralentit sur plusieurs mois

Symptôme : Même matériel, même charge (en théorie), mais la latence augmente progressivement.

Cause : Pool qui se remplit, fragmentation, plus de churn métadonnées, scrubs/resilvers qui prennent plus de temps, augmentation des ARC misses à mesure que le working set grandit.

Correctif : Conservez de la marge, ajoutez des vdevs (pas seulement des disques plus gros), tunez les propriétés des datasets, et surveillez la durée des scrubs comme métrique de tendance.

4) « On a ajouté un disque cache et c’est pire »

Symptôme : Plus de dispositifs, pire latence.

Cause : Mauvais type de cache (confusion SLOG vs L2ARC), SSD grand public sans protection contre perte d’alimentation, thrash du cache, ou domaine de faute supplémentaire.

Correctif : Mesurez les écritures sync avant d’ajouter un SLOG. Utilisez des dispositifs appropriés. Retirez le cache s’il déstabilise le système ; la stabilité prime sur la performance théorique.

5) Thin-provisioning Storage Spaces frappe soudainement un mur

Symptôme : Écritures échouent, services plantent, les volumes semblent « pas pleins ».

Cause : Capacité physique du pool épuisée alors que les disques virtuels ont encore de l’espace logique.

Correctif : Surveillez FreeSpace du pool, appliquez une politique de marge, et cessez de traiter le thin provisioning comme un plan de capacité.

6) ZFS rapporte des erreurs de checksum, mais SMART dit que le disque est correct

Symptôme : CKSUM incrémente sur un périphérique, mais les attributs SMART semblent normaux.

Cause : Mauvais câble, port expander défectueux, problèmes HBA, ou resets de lien transitoires corrompant les transferts.

Correctif : Vérifiez les logs du noyau. Remplacez les composants de chemin. Changez les baies. N’acceptez pas « SMART est propre » comme verdict quand ZFS a la preuve d’une corruption.

7) Les réparations prennent une éternité et la performance s’effondre pendant les rebuilds

Symptôme : Rebuild/repair s’exécutent pendant des jours ; la charge devient inutilisable.

Cause : Grands disques lents, configurations parité, disques SMR, trop de charge concurrente, ou mauvais contrôles QoS.

Correctif : Préférez les mirrors pour les charges sensibles à la latence, évitez SMR dans les environnements à forte reconstruction, planifiez des fenêtres de rebuild, et gardez des spares/automations prêtes.

Listes de contrôle / plan pas à pas

Si vous choisissez entre ZFS et Storage Spaces

1. Décidez ce que vous craignez le plus : la corruption silencieuse ou la complexité opérationnelle. Si vous craignez la corruption, ZFS est la réponse par défaut.
2. Inventaire des compétences : si votre équipe vit dans Windows et PowerShell, Storage Spaces peut être plus soutenable—mais seulement si vous vous engagez à apprendre les cmdlets profonds et les logs.
3. Adaptez la disposition à la charge : parité pour le froid, miroir pour le chaud. Ne négociez pas avec la physique.
4. Définissez une politique de marge : écrivez-la. Faites-la appliquer avec des quotas et des alertes.
5. Définissez une politique d’intégrité : scrubs pour ZFS ; integrity streams / réglages ReFS si vous êtes dans l’univers Windows (et testez ce qu’ils font réellement dans votre environnement).
6. Planifiez des exercices de panne : pratiquez le remplacement de disque, les jobs de réparation, et les workflows de restauration avant d’en avoir besoin.

Pas à pas : construire un déploiement ZFS sensé

1. Utilisez des HBAs, pas des contrôleurs RAID (mode IT / pass-through), pour que ZFS voie les disques honnêtement.
2. Choisissez la topologie de vdev intentionnellement : mirrors pour IOPS et vitesse de rebuild ; RAIDZ2 pour capacité avec un risque de rebuild acceptable.
3. Activez la compression (souvent zstd) sauf raison spécifique de ne pas le faire.
4. Définissez les propriétés des datasets par workload (recordsize, atime, politique sync en connaissance de cause).
5. Planifiez des scrubs et alertez sur les erreurs et les changements de durée de scrub.
6. Testez la restauration depuis snapshots/réplication. Un snapshot n’est pas une sauvegarde tant que vous ne l’avez pas restauré.
7. Gardez de la marge et planifiez les expansions en ajoutant des vdevs, pas en espérant que des disques plus gros résolvent la douleur d’allocation.

Pas à pas : rendre Storage Spaces moins mystérieux

1. Décidez miroir vs parité par volume en fonction du pattern d’écriture, pas des espoirs budgétaires.
2. Documentez l’usage du thin provisioning et définissez des alertes d’espace libre pool qui réveillent des humains.
3. Instrumentez les jobs en arrière-plan (Get-StorageJob) afin que « c’est lent » puisse être corrélé avec « il est en train de réparer ».
4. Suivez les signes d’avertissement des disques physiques et remplacez tôt. N’attendez pas « Unhealthy ».
5. Validez firmware et drivers en staging ; les drivers de stockage ne sont pas un endroit pour YOLO des mises à jour.
6. Pratiquez une réparation et mesurez son temps. Votre première réparation ne devrait pas avoir lieu pendant une panne client.

FAQ

1) ZFS est-il « plus sûr » que Storage Spaces ?

ZFS est généralement plus sûr par défaut pour l’intégrité des données parce que les checksums end-to-end et les scrubs sont natifs. Storage Spaces peut être sûr aussi,
mais il faut configurer et surveiller délibérément le comportement d’intégrité.

2) Pourquoi dit-on que ZFS demande beaucoup de RAM ?

ZFS utilise la RAM pour l’ARC cache, ce qui améliore la performance et réduit l’I/O disque. Il ne « nécessite » pas une RAM absurde pour fonctionner, mais il utilisera ce que
vous lui donnez. Sous-dimensionnez la RAM et vous le ressentirez en latence.

3) La parité de Storage Spaces est-elle toujours lente ?

La parité est intrinsèquement plus coûteuse pour les petites écritures aléatoires. Avec de gros écrits séquentiels, un bon design de cache/tier, et une charge adaptée au modèle,
cela peut être acceptable. Mais si vous promettez la latence parité à des bases OLTP, vous rédigez votre propre rapport d’incident.

4) Quel est l’équivalent ZFS de « virtual disk footprint on pool » ?

ZFS montre l’allocation au niveau pool et dataset (zfs list, zpool list). L’overhead RAIDZ n’est pas caché, mais il s’exprime via l’espace réellement alloué
et la disposition de parité plutôt que par un seul chiffre « footprint ».

5) Storage Spaces peut-il détecter le bit rot comme ZFS ?

Oui, selon le système de fichiers et les réglages (typiquement ReFS avec les features d’intégrité). En pratique, beaucoup de déploiements n’activent pas ou ne valident pas ces
fonctionnalités de bout en bout, donc la détection est moins cohérente opérationnellement.

6) Ai-je besoin d’un SLOG sur ZFS ?

Seulement si vous avez une charge significative d’écritures synchrones et que vos vdevs principaux ne peuvent pas absorber la latence. Mesurez d’abord. Si vous en ajoutez un,
utilisez un device conçu pour cela (la protection contre la perte d’alimentation compte).

7) Quel est le plus gros « piège » du thin provisioning ?

Vous pouvez manquer de capacité physique alors qu’il reste de l’espace logique. Ce mode de défaillance est abrupt et laid. Le thin provisioning n’est pas un plan de capacité ;
c’est une tactique d’utilisation qui exige une surveillance stricte.

8) Comment décider miroir vs RAIDZ/parité ?

Si vous avez besoin d’une latence prévisible et de rebuilds rapides : mirror. Si vous avez besoin d’efficacité de capacité et pouvez tolérer des écritures plus lentes et des réparations
plus longues : RAIDZ2/parité (avec assez de spindles et de marge). Si vous hésitez, le mirror est le pari opérationnel le plus sûr.

9) Lequel est plus facile à exploiter ?

ZFS est plus facile à exploiter une fois que vous l’avez appris parce que les signaux sont cohérents et locaux. Storage Spaces est plus facile à démarrer, mais peut devenir
plus difficile lorsque vous déboguez performance ou risque de capacité à travers des couches.

10) Sur quoi devrais-je alerter en premier ?

Pour ZFS : changements de zpool status, échecs de scrub, augmentation des checksum, et seuils de capacité du pool. Pour Storage Spaces : FreeSpace du pool, tout disque dont
l’état HealthStatus n’est pas « Healthy », et jobs de stockage de longue durée.

Prochaines étapes que vous pouvez réellement faire

Si vous utilisez ZFS : rendez zpool status ennuyeux. Planifiez des scrubs. Alertez sur les deltas de checksum. Suivez la durée des scrubs et les temps de resilver
comme tendances. Gardez de la marge. Et arrêtez de prétendre qu’un pool à 89% est « à peu près correct ».

Si vous utilisez Storage Spaces : cessez de faire confiance au mot « Healthy » sans contexte. Construisez un script de santé quotidien autour de
Get-PhysicalDisk, Get-VirtualDisk, Get-StoragePool et Get-StorageJob. Alertez sur FreeSpace du pool. Entraînez-vous au remplacement
d’un disque et à la réparation. Documentez exactement à quoi sert la parité, et refusez d’y mettre des charges sensibles à la latence.

Si vous hésitez : choisissez la pile dont vous pouvez expliquer les modes de panne à un ingénieur fatigué en vous appuyant sur des preuves réelles. « Facile » n’est facile que
tant qu’il reste lisible sous stress. Quand cela devient opaque, cela devient coûteux.