Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
Amélioration de la fiabilité des constructions sur disque
ReFS utilise des arbres B+ pour toutes les structures sur disque, dont les métadonnées et les données de fichiers. Les métadonnées et les fichiers sont organisés dans des tables similaires à une base de données relationnelle. La taille d'un fichier, le nombre de fichiers dans un dossier, la taille totale d'un volume et le nombre de dossiers dans un volume est limité par des nombres 64 bits ; en conséquence ReFS prend en charge une taille de fichier maximale de 16 exaoctets, un maximum de 18,4 × 1018 dossiers et une taille de volume maximum de 1 yottaoctet (avec des clusters de 64 ko), permettant ainsi une grande évolutivité sans limites pratiques sur les fichiers et la taille de dossiers (les restrictions matérielles s'appliquent toujours). L'espace libre est compté par un allocateur hiérarchique qui comprend trois tableaux distincts pour les grands, moyens et petits morceaux. Les noms de fichiers sont limités à 255 caractères Unicode tandis que les chemins d'accès sont limités à une chaîne de texte Unicode de 32 kilooctets.
Résilience intégrée
ReFS utilise une stratégie de mise à jour « allocation-on-write » pour les métadonnées, qui alloue de nouveaux blocs à chaque mise à jour de transaction et utilise des lots d'entrées-sorties de taille importante. Toutes les métadonnées ReFS ont des sommes de contrôle 64 bits qui sont stockées de façon indépendante. Les données de fichier peuvent avoir une somme de contrôle en option dans un « flux » séparée, dans ce cas, la stratégie de mise à jour du fichier implémente également l'allocation-on-write ; ceci est contrôlé par un nouvel attribut d’« intégrité » applicable à la fois aux fichiers et répertoires. Si néanmoins les données de fichiers ou les métadonnées deviennent corrompues, le fichier peut être supprimé sans mettre l'ensemble du volume hors ligne pour la tâche de maintenance, puis être restauré à partir de la sauvegarde. En conséquence de cette résilience intégrée, les administrateurs n'ont pas besoin d’exécuter régulièrement des outils de vérification d'erreurs tels CHKDSK lors de l’utilisation de ReFS.
Compatibilité avec les API et technologies existantes
Certaines fonctionnalités de NTFS ne sont pas pris en charge dans ReFS, comme les (en) flux nommés, les (en) ID d'objets, les (en) noms de fichier 8.3, la (en) compression NTFS, l'Encrypting File System (EFS), le (en) NTFS transactionnel, les liens matériels, les attributs étendus et les (en) quotas de disque. ReFS lui-même n'offre pas de déduplication des données. En outre, Windows ne peut pas être démarré à partir d'un volume ReFS. Les disques dynamiques avec des volumes mis en miroir ou entrelacés sont remplacés par des pools de stockage en miroir ou entrelacés fournis par Espaces de stockage. Toutefois, dans Windows Server 2012, la correction automatique des erreurs est uniquement gérée dans les espaces en miroir et le démarrage à partir de ReFS n'est pas non plus supporté.
Windows 8.1 ajoute le support des volumes ReFS. Par rapport à Windows Server 2012, Windows Server 2012 R2 et Windows 8.1 ajoutent des fonctionnalités supplémentaires à l'utilisation de ReFS, dont les flux de données alternatifs et une correction automatique de la corruption lorsque les flux d'intégrité sont utilisés sur les espaces de parité[3].
