Windows Server 2019 & NVMe 4K+64B : compatibilité, erreurs d’installation et solutions (4Kn, 512e, T10 DIF)

Windows Server 2019 peut-il s’installer sur un SSD NVMe au format logique 4 KiB + 64 octets de métadonnées ? Voici une explication claire des symptômes, des causes et des solutions concrètes, avec procédures pas‑à‑pas et commandes utiles.

Sommaire

Vue d’ensemble de la question

Des administrateurs tentent d’installer Windows Server 2019 sur un SSD NVMe configuré avec un format de bloc logique de 4096 o de données + 64 o de métadonnées (souvent abrégé 4K + metadata, ou LBAF « 4 KiB + 64 B »). Pendant l’installation, l’assistant Windows affiche des comportements anormaux : espaces non alloués reportés à 0 Mo, capacité incohérente, impossibilité de créer/supprimer les partitions système, et échec lors du formatage.

La raison tient à la politique de prise en charge des tailles de secteurs côté Windows : seules les variantes 512‑byte native (512n), 512e (secteurs 4K émulant 512 o) et 4Kn (4K natif sans métadonnées additionnelles) sont officiellement supportées comme formats de disque. Les formats avec métadonnées par secteur (ex. 4K + 64B, utilisés pour la Protection Information T10 DIF/PI) ne sont pas reconnus par l’installateur Windows ni par la pile de stockage du système pour l’amorçage.

Réponse et solutions, en un coup d’œil

Point clé	Détails
Pas de prise en charge native	Windows Server 2019 (et même 2022) ne propose aucune compatibilité annoncée pour les formats NVMe 4 KiB + 64 B. L’installateur se comporte de manière erratique : taille des espaces à 0 Mo, création de partitions impossible, erreurs de formatage.
Politique Windows sur les secteurs	La pile Windows prend en charge 512n, 512e et 4Kn. Les formats logiques marqués « Other » par le contrôleur (notamment ceux avec métadonnées) ne sont pas supportés pour l’installation/démarrage.
Contournement recommandé	Reformater le namespace NVMe en 4Kn sans métadonnées (métadonnées = 0). Sur de nombreux SSD, il s’agit du LBA Format « 1 » ou « 0 » selon le modèle. Exemple Linux : `nvme format -l 1 /dev/nvme0n1`. Une fois en 4Kn, l’installation de Windows Server 2019 se déroule normalement.
Autres options	Basculer en 512e si le firmware du SSD le propose ; Installer Windows sur un disque compatible (4Kn/512e), puis ajouter le namespace 4K + 64B uniquement comme volume de données non amorçable via un OS/hyperviseur qui gère T10 DIF ; Utiliser Linux (noyau récent) ou ESXi 7+ pour exploiter la protection d’intégrité de bout‑en‑bout, et exécuter Windows en VM sur un datastore compatible.
Pourquoi les 64 o ?	Les 64 octets supplémentaires servent aux métadonnées d’intégrité (T10 DIF/PI) : tag de garde, référence et application tag. Windows n’implémente pas cette intégrité au niveau bloc pour les disques système, d’où l’incompatibilité actuelle.

Ce que Windows Server 2019 prend réellement en charge

512n (512‑byte native) : historique, toujours supporté (y compris boot, MBR/UEFI selon le matériel).
512e : le disque expose 512 o logiques mais 4K physiques ; généralement compatible boot/OS.
4Kn : 4096 o logiques et physiques, sans métadonnées. Supporté par Windows Server 2019, y compris comme disque système en UEFI/GPT (selon firmware/contrôleur).
4K + métadonnées (ex. 64 B) : non supporté par la pile Windows pour l’installation ni le démarrage. Les opérations de partitionnement/formatage échouent typiquement.

Symptômes typiques pendant l’installation

Le disque NVMe apparaît avec un espace non alloué à 0 Mo ou une capacité incorrecte.
Les boutons Créer / Supprimer / Formater des partitions renvoient des erreurs vagues.
Après suppression de toutes les partitions, l’assistant refuse encore la création des partitions système.
Des boucles d’échec au formatage NTFS peuvent survenir.

Ces symptômes sont cohérents avec un format logique non supporté par la pile de stockage.

Comprendre le format 4 KiB + 64 B et T10 DIF/PI

Un contrôleur NVMe peut proposer plusieurs LBA Formats (LBAF). Pour chacun : la Data Size (ex. 4096 o) et la Metadata Size (ex. 64 o). Les 64 octets servent souvent à la Protection Information (PI), aussi appelée T10 DIF (Data Integrity Field), qui ajoute des balises par secteur pour détecter/corriger des corruptions de bout‑en‑bout entre l’hôte et le média. Cette fonction est prisée dans certains environnements de stockage d’entreprise, mais elle requiert que le système d’exploitation, les pilotes, le contrôleur et les applications gèrent cette sémantique supplémentaire. Windows Server ne l’expose pas pour le démarrage système, d’où l’échec dès l’installateur.

Vérifier rapidement le format du namespace

Depuis un environnement Linux live disposant de nvme-cli :

# Lister les formats logiques disponibles et le format en cours
nvme id-ns /dev/nvme0n1 --human-readable | sed -n '/LBA Format/p;/^ *LBA/p'
# Indice&nbsp;: la colonne "Metadata Size" doit être 0 pour Windows
# Autre vue utile&nbsp;:
lsblk -o NAME,SIZE,LOG-SEC,PHY-SEC,ROTA,MODEL

Si Metadata Size est non nul (par ex. 64), l’installateur Windows refusera de s’installer proprement.

Procédure : reformater vers un format compatible

Attention : les commandes ci‑dessous effacent définitivement toutes les données de la cible. Vérifiez le bon périphérique avant de lancer un format.

Identifier le bon LBAF à sélectionner

# Afficher tous les LBAF et repérer ceux avec Metadata Size = 0
nvme id-ns /dev/nvme0n1 -H | grep -A3 "LBA Format"
# Exemple d'interprétation&nbsp;:
# - LBA Format 0 : Data Size 4096, Metadata Size 0    =&gt; 4Kn (compatible)
# - LBA Format 1 : Data Size 4096, Metadata Size 64   =&gt; 4K+64B (non compatible)
# - LBA Format 2 : Data Size 512,  Metadata Size 0    =&gt; 512n/512e selon le disque

Formater en 4Kn (recommandé)

# Remplacer &lt;LBAF_COMPATIBLE&gt; par l'index dont Metadata Size = 0 et Data Size = 4096
sudo nvme format /dev/nvme0n1 -l &lt;LBAF_COMPATIBLE&gt;
# Certains firmwares exigent l'option --force&nbsp;:
sudo nvme format /dev/nvme0n1 -l &lt;LBAF_COMPATIBLE&gt; --force
# Après formatage, débranchez/rebranchez (ou "nvme reset") pour que le nouvel LBAF soit actif.

Redémarrez ensuite sur le média d’installation de Windows et relancez l’installation : le disque devrait apparaître avec sa capacité complète et accepter la création automatique des partitions système (EFI/MSR/Primary).

Alternative : basculer en 512e

Si le contrôleur/firmware ne permet pas un 4Kn sans métadonnées, visez un format 512e si présent :

# Repérer un LBAF avec Data Size = 512 et Metadata Size = 0
sudo nvme id-ns /dev/nvme0n1 -H
# Formater&nbsp;:
sudo nvme format /dev/nvme0n1 -l &lt;LBAF_512E&gt; --force

512e reste largement pris en charge par Windows et par la plupart des outils de sauvegarde/antivirus, au prix d’un léger compromis sur certaines charges d’E/S non alignées.

Via outil constructeur ou UEFI

De nombreux fournisseurs proposent un utilitaire bootable ou une option UEFI NVMe Format permettant de changer le LBAF sans passer par Linux. Le principe reste le même : sélectionner un format avec Metadata Size = 0.

Procédure alternative si le 4K + 64B est impératif

Si votre environnement exige la protection T10 DIF pour des volumes de données, deux voies existent :

Installer Windows sur un disque compatible (SATA/NVMe 4Kn/512e), puis présenter le namespace 4K + 64B à un autre OS/hyperviseur (Linux récent, ESXi 7+) comme datastore/volume secondaire. Windows s’exécute alors en machine virtuelle ou accède au volume via un service réseau (SMB/NFS/iSCSI) géré par l’OS qui supporte PI.
Segmenter l’usage : Windows pour la couche applicative, appliance/serveur Linux pour les volumes à intégrité renforcée. Les flux entre couches se font par protocole standard (ex. iSER/NVMe‑oF).

Dans ces scénarios, le namespace 4K + 64B n’est pas amorçable par Windows et ne doit pas contenir les partitions système EFI/Boot.

Vérifications après installation

Une fois Windows Server 2019 installé (sur 4Kn ou 512e), validez l’alignement et les tailles de secteurs :

# PowerShell : tailles de secteurs
Get-PhysicalDisk | ft FriendlyName,MediaType,LogicalSectorSize,PhysicalSectorSize

# Vue disque/partitions

Get-Disk | ft Number,FriendlyName,PartitionStyle,LogicalSectorSize,PhysicalSectorSize
Get-Partition | ft DiskNumber,PartitionNumber,DriveLetter,Size

# Détails NTFS du volume (remplacer X: par la lettre)

fsutil fsinfo ntfsinfo X:

Les valeurs courantes attendues : 4096/4096 pour 4Kn, 512/4096 pour 512e. Si d’autres tailles apparaissent (ex. présence de métadonnées), l’installation initiale n’a pas été réalisée sur ce disque ou le contrôleur présente une translation.

Bonnes pratiques et impacts en production

Choix du format : privilégiez 4Kn pour les charges modernes (SQL, virtualisation, fichiers volumineux). 512e reste pertinent pour la compatibilité applicative maximale et certains outils de sauvegarde anciens.
Alignement : la plupart des partitions créées par Windows sont déjà alignées sur 1 MiB (multiples de 4K). Évitez les outils tiers qui imposent des schémas d’alignement hérités (63 secteurs, etc.).
Chiffrement : BitLocker fonctionne avec 4Kn et 512e. Sur 4Kn, vérifiez l’accélération matérielle du processeur et du contrôleur.
Firmware/driver : mettez à jour l’UEFI, le firmware NVMe et les pilotes de stockage NVMe/Chipset.
Imagerie/Sauvegarde : certains utilitaires très anciens ne gèrent pas 4Kn. Utilisez des outils récents compatibles VSS et 4K.

Diagnostic approfondi : que regarde l’installateur Windows ?

Lorsqu’on sélectionne un disque cible, l’installateur vérifie :

La taille logique du secteur présentée par le namespace (512 ou 4096).
L’absence de métadonnées sémantiques non comprises par la pile (PI/DIF, etc.).
Le style de partition (GPT recommandé pour UEFI, avec partitions EFI/MSR) et la capacité minimale du disque.
La prise en charge du contrôleur (pilote NVMe présent, pas d’exigence propriétaire).

En présence de métadonnées par secteur, les opérations de partitionnement échouent en amont : Windows ne sait pas écrire un système de fichiers qui coexiste avec des balises PI par secteur.

Scénarios d’erreur courants et résolutions

Symptôme	Cause probable	Correctif
Espace non alloué = 0 Mo	Format logique non supporté (4K + métadonnées)	Reformater le namespace en 4Kn (Metadata = 0) ou 512e
Impossible de créer la partition système	Installateur ne peut pas écrire la table/GPT sur ce LBAF	Changer de LBAF, vérifier firmware NVMe/UEFI, relancer
Erreur au formatage NTFS	Pile de stockage refuse la couche métadonnées	Formater le disque côté Linux/outil constructeur en 4Kn, puis réessayer
Capacité reportée incorrecte	Traduction contrôleur + métadonnées par secteur	Réinitialiser le namespace, supprimer HDR propriétaires, 4Kn/512e

Étapes pas‑à‑pas : de l’échec à la réussite

Démarrez un Linux live avec nvme-cli.
Identifiez le namespace cible : nvme list nvme id-ns /dev/nvme0n1 -H | sed -n '/LBA Format/p;/^ *LBA/p'
Notez le LBAF sans métadonnées (Metadata Size = 0), idéalement Data Size = 4096.
Lancez le formatage vers ce LBAF : sudo nvme format /dev/nvme0n1 -l <INDEX_SANS_METADATA> --force
Coupez l’alimentation du SSD (ou nvme reset), redémarrez.
Relancez l’installation Windows, laissez l’assistant créer les partitions par défaut.
Après installation, validez les tailles de secteurs sous PowerShell (commandes ci‑dessus).

Commandes utiles côté Windows (préparation/validation)

# Nettoyage complet d'un disque cible (attention : destructif)
diskpart
list disk
select disk <N>
clean
convert gpt
exit

# Vérifier les tailles de secteurs et l'état des disques

Get-PhysicalDisk | ft FriendlyName,MediaType,LogicalSectorSize,PhysicalSectorSize,CanPool
Get-Disk | ft Number,PartitionStyle,OperationalStatus,LogicalSectorSize,PhysicalSectorSize

FAQ

Peut‑on démarrer Windows directement depuis un namespace 4K + 64B ?
Non. Ce format introduit des métadonnées par secteur (PI/DIF) que Windows ne gère pas pour le disque système.

Si je présente le namespace 4K + 64B via un contrôleur RAID/SAN qui masque les métadonnées, est‑ce supporté ?
Si le contrôleur expose à Windows un volume logique en 4Kn ou 512e (sans métadonnées visibles), alors oui, côté Windows le volume est supporté. C’est le contrôleur qui assume la gestion de l’intégrité.

4Kn est‑il un meilleur choix que 512e ?
4Kn élimine l’émulation 512 o et optimise l’alignement, utile pour de gros fichiers et des IOPS séquentielles. 512e maximise la compatibilité avec d’anciens logiciels. Choisissez selon vos contraintes applicatives et vos outils.

Quelles précautions avant de reformater ?
Sauvegardez, vérifiez l’index LBAF, comprenez que format réinitialise la structure interne du namespace. Sur certains SSD, l’opération peut durer plusieurs minutes et invalider le cache d’écriture.

Checklist rapide

Le namespace NVMe est‑il sans métadonnées (Metadata Size = 0) ?
Le Data Size vaut‑il 4096 (4Kn) ou 512 (512e) ?
UEFI/BIOS et firmware NVMe sont‑ils à jour ?
Le disque est‑il en GPT pour un démarrage UEFI ?
Les tailles de secteurs attendues sont‑elles visibles dans PowerShell ?

Matrice de compatibilité condensée

Format du disque	Installation Windows Server 2019	Démarrage	Usage recommandé
512n	Oui	Oui (MBR/UEFI selon plateforme)	Compatibilité maximale, environnements hétérogènes
512e	Oui	Oui (UEFI/GPT recommandé)	Prise en charge large, compromis raisonnable
4Kn (4096/4096, metadata 0)	Oui	Oui (UEFI/GPT)	Performances/alignement, charges modernes
4K + 64B (PI/DIF)	Non	Non	Réservé aux OS/hyperviseurs qui gèrent PI (Linux, ESXi)

Conclusion

Windows Server 2019 ne peut ni s’installer ni démarrer sur un SSD NVMe configuré en 4 KiB + 64 B. Cette configuration s’appuie sur des métadonnées d’intégrité (T10 DIF/PI) que la pile de stockage Windows ne supporte pas pour les disques système. La voie fiable est de reformater le namespace en 4Kn (metadata = 0) ou, à défaut, en 512e avant l’installation. Si la protection PI est indispensable pour des volumes de données, déléguez‑la à un hyperviseur ou un OS compatible et exécutez Windows au‑dessus, ou confiez la gestion des métadonnées à un contrôleur qui expose à Windows un format standard (4Kn/512e).

Annexe : modèle de procédure “zéro surprise”

Boot Linux live → nvme id-ns -H → noter LBAF sans métadonnées.
nvme format -l <index_sans_metadata> --force → redémarrage.
Installer Windows en UEFI/GPT → laisser l’assistant créer les partitions.
PowerShell → Get-PhysicalDisk / Get-Disk / fsutil → vérifier 4Kn/512e.
Appliquer mises à jour pilote NVMe/Chipset et firmware UEFI.

Rappels importants

Un format NVMe réinitialise le namespace : sauvegardez et validez deux fois la cible.
Certains SSD exposent les LBAF différemment (indexation constructeur). Fiez‑vous aux champs Data Size et Metadata Size, pas au numéro.
Si vous voyez des tailles exotiques (ex. 520/528 o héritées des baies SAN), Windows réagira de la même manière : non support.

En pratique : la solution la plus rapide et robuste consiste à repasser le disque en 4Kn (Metadata Size = 0), installer Windows, puis — si nécessaire — réserver les namespaces à métadonnées aux plateformes qui savent en tirer parti.