Un formatage NTFS bloqué sur un cluster Hyper-V peut rapidement faire penser à un problème PowerShell, MPIO ou Failover Clustering. Pourtant, dans notre cas, la cause réelle se cachait dans un paramètre UNMAP activé sur les LUN du SAN.
Symptômes d’un formatage NTFS bloqué sur Hyper-V
Le symptôme était toujours le même :
Format-Volumebloqué à 0% ou 50%- retour
code 8 - console MMC “Gestion des disques” figée
Get-Diskqui ne répond plus- nœud cluster temporairement indisponible
- reboot obligatoire pour récupérer la stack storage
Au départ, tout semblait pointer vers PowerShell, StorageWMI ou Failover Clustering. Pourtant, plusieurs indices montraient que le problème était plus bas niveau :
- les LUN étaient visibles ;
- MPIO fonctionnait correctement ;
- les partitions GPT étaient créées sans problème ;
- le cluster pouvait ajouter les disques ;
- même DiskPart finissait par bloquer sur :
format fs=ntfs quick unit=64k
Le vrai déclencheur était uniquement la création du système de fichiers NTFS.
Le point clé a finalement été un détail connu mais oublié côté baie SAN : un paramètre UNMAP/T10 configurable directement sur les LUN.
Lorsque l’option était activée :
- les formatages NTFS provoquaient des timeouts storage ;
- le cluster devenait instable ;
- certains nœuds décrochaient temporairement ;
- MMC et les cmdlets storage devenaient inutilisables.
Lorsque l’option était désactivée :
- les formatages fonctionnaient immédiatement ;
- le cluster redevenait stable.
Le plus trompeur dans ce type d’incident est qu’un simple “quick format” moderne envoie déjà des commandes TRIM/UNMAP agressives vers le SAN.
TRIM et UNMAP : quelle différence ?
Les deux termes sont souvent utilisés comme synonymes, mais ils ne désignent pas exactement la même chose.
- TRIM correspond au mécanisme côté système de fichiers Windows ;
- UNMAP correspond à la commande SCSI/T10 réellement envoyée au stockage.
Concrètement :
NTFS/ReFS
→ TRIM logique
→ UNMAP SCSI
→ baie SAN
Lorsque Windows supprime des blocs inutiles, le SAN peut récupérer cet espace sur des LUN thin provisioned.
Pourquoi désactiver TRIM peut stabiliser un cluster
La commande suivante désactive l’envoi des notifications TRIM/UNMAP côté Windows :
fsutil behavior set DisableDeleteNotify NTFS 1
Dans ce cas :
- Windows n’envoie plus d’UNMAP ;
- le SAN ne reçoit plus les commandes problématiques ;
- les formatages NTFS cessent de bloquer.
En revanche, cela a une conséquence importante : le SAN ne sait plus réellement quels blocs ont été libérés.
Résultat :
- l’espace thin provisioned peut sembler artificiellement consommé ;
- la baie perd une partie de sa visibilité sur l’occupation réelle ;
- le reclaim automatique devient moins efficace.
Le point important est que, dans ce cas, le paramètre UNMAP était porté par la LUN et non par la baie dans son ensemble. Désactiver UNMAP sur une LUN problématique ne désactive donc pas la fonctionnalité pour tout le SAN.
Les autres LUN, présentées à des hôtes compatibles ou à des workloads qui supportent correctement UNMAP, peuvent continuer à en bénéficier normalement.
C’est une nuance importante : le contournement peut rester ciblé uniquement sur les volumes présentés aux clusters problématiques, sans pénaliser l’ensemble de l’infrastructure.
Dans notre cas, le compromis était finalement acceptable : perdre une partie du reclaim automatique restait largement préférable à un cluster Hyper-V capable de devenir instable pendant un simple formatage NTFS.
