Création du système de fichiers de prochaine génération pour Windows : ReFS

Nous souhaitons poursuivre notre conversation sur le stockage des données en parlant du système de fichiers de prochaine génération introduit dans Windows 8. De nos jours, le système de fichiers NTFS est le plus largement utilisé, le plus avancé et le plus riche en fonctionnalités. Mais lorsqu'on réimagine Windows, comme nous le faisons pour Windows 8, on ne se repose pas sur des succès passés. Avec Windows 8, nous introduisons donc également une nouvelle conception du système de fichiers. Comme ReFS (abréviation de Resilient File System, système de fichiers fiable) repose sur les fondations de NTFS, il conserve une compatibilité cruciale tout en étant conçu pour une prochaine génération de technologies et de scénarios de stockage. Dans Windows 8, ReFS sera introduit uniquement dans le cadre de Windows Server 8, démarche que nous avons toujours suivie pour chaque introduction de nouveaux systèmes de fichiers. Bien sûr, au niveau de l'application, les données ReFS stockées seront accessibles à partir des clients tout comme le seraient les données NTFS. En lisant ceci, n'oubliez pas que NTFS est de loin la technologie à la pointe de l'industrie pour les systèmes de fichiers sur PC.

Ce billet architectural détaillé a été rédigé par Surendra Verma, responsable du développement au sein de notre équipe Stockage et système de fichiers, même si, comme c'est le cas pour chaque fonctionnalité, beaucoup de personnes y ont participé. De plus, nous avons également adopté le mode FAQ dans ce billet.
--Steven

PS : n'oubliez pas de nous suivre sur @buildwindows8, où nous donnons les dernières informations de CES.  

---

Dans ce billet, je souhaite parler d'un nouveau système de fichiers pour Windows. Ce système de fichiers, que nous appelons ReFS, a été entièrement conçu pour répondre aux besoins d'un grand nombre de clients, actuels et futurs, quant à toutes les différentes façons dont Windows est déployé.

Les principaux objectifs de ReFS sont les suivants :

• Maintenir un degré de compatibilité élevé avec un sous-ensemble de fonctionnalités NTFS largement adoptées tout en s'éloignant d'autres fonctionnalités dont les avantages limités pèsent sur la complexité et l'encombrement du système.
• Vérifier et corriger automatiquement les données. Les données peuvent être endommagées pour un certain nombre de raisons et par conséquent, elles doivent être vérifiées et, lorsque cela est possible, corrigées automatiquement. Les métadonnées ne doivent pas être écrites en place pour éviter la possibilité « d'écritures endommagées », dont nous parlerons plus en détail plus loin.
• Optimiser pour une évolutivité extrême. Utilisez des structures évolutives pour tout. Ne supposez pas que les algorithmes de vérification des disques, en particulier, peuvent s'adapter à la taille du système de fichiers entier.
• Ne jamais mettre le système de fichiers hors connexion. Imaginez qu'en cas de dommages, il est avantageux d'isoler l'erreur tout en autorisant l'accès au reste du volume. Cela s'effectue tout en récupérant le maximum de données possible, tout cela en ligne.
• Fournir une architecture entièrement fiable de bout en bout lorsqu'elle est utilisée avec la fonctionnalité Storage Spaces, qui a été conçue et créée conjointement avec ReFS.

Les principales fonctionnalités de ReFS sont les suivantes (notez que certaines de ces fonctionnalités sont fournies conjointement avec Storage Spaces).

• Intégrité des métadonnées avec sommes de contrôle
• Flux d'intégrité fournissant une intégrité facultative des données utilisateur
• Modèle transactionnel d'allocation sur écriture pour les mises à jour robustes des disques (fonctionnalité également connue sous le nom de copie sur écriture)
• Taille élevée des volumes, fichiers et répertoires
• Le regroupement et la virtualisation du stockage facilitent la création et la gestion du système de fichiers
• Agrégation par bandes des données pour les performances (la bande passante peut être gérée) et redondance pour la tolérance de panne
• Contrôle du disque pour le protéger contre les erreurs latentes
• Résistance aux dommages avec « récupération » pour une disponibilité maximale du volume dans tous les cas
• Pools de stockage partagés entre les machines pour renforcer la tolérance de panne et l'équilibrage de charge

En outre, ReFS hérite des fonctionnalités et de la sémantique de NTFS, notamment le chiffrement BitLocker, les listes de contrôle d'accès pour la sécurité, le journal USN, les notifications de modification, les liens symboliques, les points de jonction, les points de montage, les points d'analyse, les captures instantanées de volume, les identifiants de fichiers et les verrous optionnels.

Et bien sûr, les données stockées sur ReFS sont accessibles par les mêmes API d'accès aux fichiers sur les clients que celles qui sont utilisées sur n'importe quel système d'exploitation pouvant accéder aux volumes NTFS actuels.

Principaux attributs et fonctionnalités de conception

Nos attributs de conception sont étroitement liés à nos objectifs. Lors du passage en revue de ces attributs, gardez à l'esprit l'histoire de la création de systèmes de fichiers utilisés par des centaines de millions de périphériques allant des plus petites machines aux plus vastes centres de données, du plus petit format de stockage au plus grand format à plusieurs piles de disque, du stockage SSD aux plus grands disques et systèmes de stockage disponibles. Et pourtant dans le même temps, les systèmes de fichiers Windows sont utilisés par le plus vaste réseau qui soit d'applications et de logiciels système. ReFS prend en compte ce fait et s'y appuie. Nous n'avons pas tout recommencé depuis le début, mais nous l'avons réimaginé lorsque cela semblait judicieux et avons repris les parties intéressantes de NTFS lorsque cela semblait logique. Par dessus tout, nous procédons de manière pragmatique et cohérente avec la création d'un tel système de fichier d'importance majeure (quelque chose que seul Microsoft a fait à cette échelle).

Réutilisation et compatibilité du code

L'API du système de fichiers est la partie où la compatibilité est primordiale et techniquement, la plus problématique. Réécrire le code qui implémente la sémantique du système de fichiers ne conduirait pas au niveau de compatibilité voulu et les problèmes introduits seraient hautement liés au code de l'application, au minutage des appels et au matériel. Par conséquent, nous avons réutilisé le code à l'origine de l'implémentation de la sémantique du système de fichiers Windows pour créer ReFS. Ce code implémente l'interface du système de fichiers (lecture, écriture, ouverture, fermeture, notification de modification, etc.), préserve l'état des fichiers et volumes en mémoire, renforce la sécurité et gère la mise en cache mémoire et la synchronisation des données de fichier. Cette réutilisation assure un degré élevé de compatibilité avec les fonctionnalités de NTFS que nous reprenons.

En arrière-plan de cette portion réutilisée, la version NTFS du code base utilise un moteur récemment mis en place et qui implémente des structures sur le disque, telles que MFT (Master File Table, Table de fichiers maîtres), pour représenter les fichiers et répertoires. ReFS allie ce code réutilisé à un nouveau moteur, dans lequel une part importante de l'innovation sous-jacente à ReFS repose. Voici une représentation graphique :

Structures sur disque fiables et évolutives

Les structures sur disque et leur manipulation sont gérées par le moteur de stockage sur disque. Cela donne lieu à une interface clé-valeur générique, que la couche ci-dessus utilise pour implémenter les fichiers, les répertoires, etc. Pour sa propre implémentation, le moteur de stockage utilise des arbres B+ (B+ Trees) exclusivement. En fait, nous utilisons les arbres B+ comme unique structure sur disque commune pour représenter toutes les informations du disque. Les arbres peuvent être incorporés dans d'autres arbres (la racine d'un arbre enfant est stockée dans la rangée d'un arbre parent). Sur le disque, les arbres peuvent être très grands et à plusieurs niveaux ou très compacts avec seulement quelques clés et incorporés dans une autre structure. Cela donne lieu à une évolutivité extrême vers le bas ou le haut pour tous les aspects du système de fichiers. Disposer d'une seule structure simplifie énormément le système et réduit le code. L'interface du nouveau moteur inclut la notion de « tables » qui sont des jeux de paires clé-valeur pouvant être énumérés. La plupart des tables possèdent un identifiant unique (appelé ID objet) par lequel elles peuvent être référencées. Une table d'objet spéciale indexe toutes ces tables dans le système.

Regardons maintenant comment les abstractions communes du système de fichiers sont construites avec les tables.

Structures de fichiers

Comme le montre le diagramme ci-dessus, les répertoires sont représentés par des tables. Comme nous implémentons les tables à l'aide d'arbres B+, les répertoires peuvent évoluer efficacement pour devenir très grands. Les fichiers sont implémentés en tant que tables incorporées dans une rangée du répertoire parent, lui-même une table (représentation en tant que Métadonnées de fichier dans le diagramme ci-dessus). Les rangées au sein de la table Métadonnées de fichier représentent les différents attributs de fichier. Les emplacements de l'étendue des données de fichier sont représentés par une table de flux incorporée, qui est une table de correspondances de décalage (et facultativement, de sommes de contrôle). Cela signifie que les fichiers et répertoires peuvent être très importants sans impact sur les performances, ce qui élimine les limitations inhérentes à NTFS.

Comme prévu, les autres structures globales du système de fichiers, telles que les listes de contrôle d'accès (ACL, Access Control List) sont représentées par des tables dont la racine se trouve dans la table d'objet.

L'intégralité de l'allocation de l'espace disque est géré par un allocateur hiérarchique, qui représente l'espace libre par des tables de rangées d'espace libre. Pour l'évolutivité, il existe trois tables de ce type : les grands, moyens et petits allocateurs. Ils diffèrent dans la granularité de l'espace qu'ils gèrent : par exemple, un allocateur moyen gère des groupes de taille moyenne alloués par le grand allocateur. Cela permet une très bonne évolutivité des algorithmes d'allocation de disque et nous permet de bénéficier de métadonnées associées naturellement colocalisées pour de meilleures performances. Les racines de ces allocateurs, ainsi que celles de la table d'objet, sont accessibles à partir d'un emplacement bien connu sur le disque. Certaines tables disposent d'allocateurs qui leur sont privés, ce qui réduit les conflits et encourage une meilleure allocation locale.

À part les tables de métadonnées du système global, les entrées dans la table d'objet font référence aux répertoires, car les fichiers sont incorporés au sein des répertoires.

Stratégie fiable de mise à jour du disque

Actualiser la fiabilité et l'efficacité du disque est l'un des aspects les plus importants et les plus difficiles de la conception d'un système de fichiers. Nous avons passé beaucoup de temps à évaluer différentes approches. Une des approches que nous avons envisagée et rejetée consistait à implémenter un système de fichiers structuré par journal. Cette approche convient au type de système de fichiers polyvalent requis par Windows. NTFS repose sur un journal de transactions pour assurer la cohérence sur le disque. Cette approche met à jour les métadonnées en place sur le disque et utilise un journal pour suivre les changements qui peuvent être annulés lors d'erreurs et lors d'une récupération en cas de panne d'alimentation. Un des avantages de cette approche est qu'elle gère la disposition des métadonnées en place, ce qui peut être intéressant pour les performances de lecture. Les principaux inconvénients d'un système de journalisation sont que les écritures peuvent devenir aléatoires, et plus important, l'action de mise à jour du disque peut endommager les métadonnées déjà écrites en cas de panne d'alimentation au moment de l'écriture. Ce problème est généralement connu sous le nom d'écritures endommagées.

Pour renforcer la fiabilité et éliminer les écritures endommagées, nous avons choisi une approche d'allocation sur écriture qui ne met jamais à jour les métadonnées en place, mais les écrit à la place dans un autre emplacement de façon atomique. D'une certaine façon, cette approche s'inspire de la très ancienne notion de « pagination de cliché instantané » qui est utilisée pour mettre à jour de façon fiable les structures sur le disque. Les transactions reposent sur cette approche d'allocation sur écriture. Comme la couche supérieure de ReFS découle de NTFS, le nouveau modèle de transaction utilise pleinement la logique de reprise après incident déjà présente, qui a été testée et stabilisée au fil de plusieurs versions.

ReFS alloue les métadonnées d'une façon qui permet aux écritures d'être combinées pour des parties associées (par exemple l'allocation de flux, les attributs de fichier, les noms de fichier et les pages de répertoire) dans moins d'E/S plus grandes, ce qui est parfaitement approprié au support et à la mémoire flash en rotation. Parallèlement, une mesure de proximité de lecture est conservée. Le modèle d'allocation hiérarchique est lourdement réutilisé ici.

Nous effectuons des tests importants dans lesquels l'alimentation est retirée du système alors que ce dernier connaît une pression énorme ; une fois le système récupéré, toutes les structures sont examinées pour voir si elles sont correctes. Ces tests constituent l'ultime mesure de notre succès. Nous avons atteint un niveau de fiabilité sans précédent dans ce test des systèmes de fichiers Microsoft. Nous pensons qu'il est à la pointe de l'industrie et qu'il satisfait nos objectifs clés de conception.

Résistance à l'endommagement du disque

Comme indiqué précédemment, un de nos objectifs de conception était de détecter et de corriger les dommages. Cela assure non seulement l'intégrité des données, mais améliore également la disponibilité du système et l'opération en ligne. Ainsi, toutes les métadonnées ReFS font l'objet d'une somme de contrôle au niveau d'une page de type arbre B+ et la somme de contrôle est stockée indépendamment de la page elle-même. Cela nous permet de détecter toutes les formes d'endommagement du disque, notamment les écritures perdues et mal dirigées et la corruption des bits (dégradation des données sur le support). En outre, nous avons ajouté une option dans laquelle le contenu d'un fichier fait également l'objet d'une somme de contrôle. Lorsque cette option, connue sous le nom de « flux d'intégrité », est activée, ReFS écrit toujours les modifications du fichier dans un autre emplacement que celui d'origine. Cette technique d'allocation sur écriture assure que les données déjà existantes ne sont pas perdues en raison de la nouvelle écriture. La mise à jour de la somme de contrôle s'effectue de façon atomique avec l'écriture de données, de sorte que si l'alimentation est perdue lors de l'écriture, nous disposons toujours d'une version constamment vérifiable du fichier, dans laquelle les dommages peuvent être détectés avec autorité.

Nous avons déjà parlé de Storage Spaces sur ce blog il y a quelques semaines. Nous avons conçu ReFS et Storage Spaces pour qu'ils se complètent et qu'ils soient deux composants d'un système de fichiers complet. Nous rendons Storage Spaces disponible pour NTFS (et les PC clients) car son utilité est très grande. La superposition architecturale prend en charge cette approche côté client tandis que nous adaptons ReFS pour l'utiliser sur les clients afin que vous puissiez finalement utiliser ReFS à la fois sur les clients et les serveurs.

Outre l'amélioration des performances, Storage Spaces protège les données vis-à-vis des défaillances partielles et complètes des disques en gérant plusieurs copies sur plusieurs disques. Lors de défaillances de lecture, Storage Spaces est capable de lire d'autres copies, et lors de défaillances d'écriture (ainsi qu'en cas de perte totale de support lors de la lecture/écriture), il est capable de réallouer les données de façon transparente. De nombreuses défaillances n'impliquent pas de défaillance de support, mais surviennent en raison d'endommagement des données, ou d'écritures perdues ou mal dirigées.

Il s'agit exactement des défaillances que ReFS peut détecter à l'aide des sommes de contrôle. Lorsque ReFS détecte une telle défaillance, il interagit avec Storage Spaces pour lire toutes les copies de données disponibles et choisit la copie correcte en fonction de la validation des sommes de contrôle. Il indique ensuite à Storage Spaces de corriger les copies incorrectes en se basant sur des copies correctes. Du point de vue de l'application, tout ceci se passe de façon transparente. Si ReFS ne s'exécute pas par-dessus une version répliquée en miroir de Storage Spaces, il n'a aucun moyen de réparer automatiquement le dommage. Dans ce cas, il consignera simplement un événement indiquant qu'un dommage a été détecté et que la lecture a échoué s'il s'agit de données de fichier. Je parlerai ultérieurement davantage de l'impact de cela sur les métadonnées.

Les sommes de contrôle (64 bits) sont toujours activées pour les métadonnées ReFS et si l'on suppose que le volume est hébergé sur une version répliquée en miroir de Storage Space, la correction automatique est également activée. Tous les flux d'intégrité (voir ci-dessous) sont protégés de la même manière. Cela crée une solution d'intégrité complète pour le client, grâce à laquelle le stockage relativement non fiable peut être transformé en stockage hautement fiable.

Flux d'intégrité

Les flux d'intégrité protègent le contenu des fichiers contre toutes les formes d'endommagement des données. Bien que cette fonctionnalité soit précieuse dans de nombreux cas, elle ne convient pas pour certains. Par exemple, certaines applications préfèrent gérer leur stockage de fichiers attentivement et s'appuient sur une disposition particulière des fichiers sur le disque. Comme les flux d'intégrité réallouent les blocs à chaque fois que le contenu des fichiers est modifié, la disposition des fichiers est trop imprévisible pour ces applications. Les systèmes de bases de données en sont d'excellents exemples. Ces applications gèrent également généralement leurs propres sommes de contrôle du contenu des fichiers et sont en mesure de vérifier et de corriger les données par une interaction directe avec les API de Storage Spaces.

Dans les cas où une disposition particulière des fichiers est requise, nous fournissons des mécanismes et des API pour contrôler ce paramètre à différents niveaux de granularité.

Au niveau le plus basique, l'intégrité est un attribut d'un fichier (FILE_ATTRIBUTE_INTEGRITY_STREAM). C'est également un attribut d'un répertoire. Lorsque l'intégrité est présente dans un répertoire, elle est héritée par tous les fichiers et répertoires qui se trouvent à l'intérieur de ce répertoire. Pour des raisons pratiques, vous pouvez utiliser la commande « format » pour spécifier cela pour le répertoire racine d'un volume au moment du formatage. Sa définition sur la racine permet d'assurer sa propagation par défaut sur chaque fichier et répertoire du volume. Par exemple :

 D:\>format /fs:refs /q /i:enable <volume>

D:\>format /fs:refs /q /i:disable <volume>

Par défaut, lorsque le commutateur /i n'est pas spécifié, le comportement que le système choisit varie selon que le volume réside ou non sur un espace répliqué en miroir. Sur un espace répliqué en miroir, l'intégrité est activée, car nous pensons que les avantages sont bien supérieurs aux coûts. Les applications peuvent toujours remplacer cet état par programmation pour chaque fichier.

Lutte contre la « corruption des bits »

Comme nous l'avons décrit plus tôt, la combinaison de ReFS et de Storage Spaces fournit un haut degré de tolérance des données en présence de dommages sur les disques et de défaillances de stockage. Une forme de perte de données qui est plus difficile à détecter et à gérer se produit en raison d'une « corruption des bits », où des parties du disque développent des dommages au fil du temps, dommages qui ne sont pas détectés, car ces parties ne sont pas lues fréquemment. Au moment où elles sont finalement lues et où les dommages sont détectés, les autres copies peuvent également avoir été endommagées ou perdues en raison d'autres défaillances.

Pour contrer ce problème, nous avons ajouté une tâche système qui contrôle régulièrement toutes les métadonnées et les données du flux d'intégrité sur un volume ReFS résidant sur une version répliquée en miroir de Storage Space. Le contrôle implique la lecture de toutes les copies redondantes et la validation de leur exactitude à l'aide de sommes de contrôle ReFS. Si les sommes de contrôle ne correspondent pas, les copies incorrectes sont corrigées à l'aide des bonnes copies.

L'attribut de fichier FILE_ATTRIBUTE_NO_SCRUB_DATA indique que le contrôleur doit ignorer le fichier. Cet attribut est utile pour les applications qui gèrent leurs informations d'intégrité, lorsque le développeur d'applications souhaite surveiller plus étroitement quand et comment ces fichiers sont contrôlés.

L'outil en ligne de commande Integrity.exe est une façon efficace de gérer les services d'intégrité et de contrôle.

Quand toutes les autres solutions échouent…disponibilité continue des volumes

Nous espérons que de nombreux clients utiliseront ReFS avec la version répliquée en miroir de Storage Spaces, auquel cas les dommages seront automatiquement réparés de façon transparente. Mais dans de rares cas, même un volume sur un espace répliqué en miroir peut être endommagé, par exemple une mémoire système défectueuse peut endommager des données, qui peuvent ensuite pénétrer le disque et endommager toutes les copies redondantes. En outre, certains clients peuvent choisir de ne pas utiliser un espace de stockage répliqué en miroir sous ReFS.

Dans les cas où le volume est endommagé, ReFS implémente la « récupération », une fonctionnalité qui supprime les données endommagées de l'espace de noms sur un volume dynamique. L'intention sous-jacente de cette fonctionnalité est de s'assurer que les dommages non réparables n'affectent pas de façon négative la disponibilité des données correctes. Si, par exemple, un seul fichier d'un répertoire était endommagé et ne pouvait pas être réparé automatiquement, ReFS supprimerait ce fichier de l'espace de noms du système de fichiers tout en récupérant le reste du volume. Cette opération peut généralement s'effectuer en moins d'une seconde.

Normalement, le système de fichiers ne peut pas ouvrir ou supprimer un fichier endommagé, ce qui place un administrateur dans l'incapacité de réagir. Mais comme ReFS peut toujours récupérer les données endommagées, l'administrateur est en mesure de récupérer ce fichier à partir d'une sauvegarde ou de demander à l'application de le recréer sans mettre le système de fichiers hors connexion. Cette innovation clé permet de s'assurer que vous n'avez pas besoin d'exécuter un outil coûteux de vérification et de correction hors connexion du disque et permet à des volumes de données très volumineux d'être déployés sans risquer de longues périodes hors connexion en raison des dommages.

Un ajustement parfait dans la pile de stockage Windows

Nous savions que notre conception devait bénéficier d'une flexibilité et d'une compatibilité optimales. Nous avons conçu ReFS pour qu'il s'intègre à la pile de stockage comme n'importe quel autre système de fichier, pour optimiser la compatibilité avec les autres couches qui l'entourent. Par exemple, il peut utiliser pleinement le chiffrement BitLocker, les listes de contrôle d'accès pour la sécurité, le journal USN, les notifications de modification, les liens symboliques, les points de jonction, les points de montage, les points d'analyse, les captures instantanées de volume, les identifiants de fichiers et les verrous optionnels. Nous sommes convaincus que la plupart des filtres des systèmes de fichiers fonctionneront sans difficulté avec ReFS avec peu de modifications, voire aucune. Nos tests corroborent cela ; par exemple, nous avons été en mesure de valider la fonctionnalité de la solution antivirus Forefront existante.

Certains filtres qui dépendent du format physique NTFS devront être davantage modifiés. Nous avons mis en place un programme intensif de compatibilité dans lequel nous testons nos systèmes de fichiers avec des logiciels tiers antivirus, de sauvegarde et autres. Nous procédons de même pour ReFS et collaborerons avec nos principaux partenaires pour résoudre les éventuelles incompatibilités que nous pouvons être amenés à découvrir. Nous avons déjà procédé ainsi par le passé, ce n'est pas unique à ReFS.

Un aspect à noter concernant la flexibilité est que, bien que ReFS et Storage Spaces fonctionnent parfaitement ensemble, ils sont conçus pour s'exécuter indépendamment l'un de l'autre. Cela donne lieu à une flexibilité de déploiement maximale pour les deux composants sans inutilement se limiter l'un l'autre. En d'autres termes, des compromis en termes de fiabilité et de performances peuvent être réalisés dans le choix d'une solution de stockage complète, notamment le déploiement de ReFS avec un stockage sous-jacent de nos partenaires.

Avec Storage Spaces, un outil de stockage peut être partagé par plusieurs ordinateurs et les disques virtuels peuvent passer de l'un à l'autre sans problème, ce qui renforce la résistance aux pannes. En raison de la façon dont nous avons architecturé le système, ReFS peut en tirer pleinement parti.

Utilisation

Nous avons testé ReFS avec un vaste ensemble sophistiqué de dizaines de milliers de tests qui ont été développés ces vingt dernières années pour NTFS. Ces tests simulent et vont au-delà des conditions requises pour les déploiements auxquels nous nous attendons en termes de contraintes sur le système, de défaillances telles qu'une panne d'alimentation, d'évolutivité et de performances. Par conséquent, le déploiement de ReFS est prêt à être testé dans un environnement géré. Comme il s'agit de la première version d'un système de fichiers majeur, nous suggérons un peu de prudence. Nous ne caractérisons pas ReFS sous Windows 8 comme une fonctionnalité « bêta ». La version livrée à la fin de la version bêta de Windows 8 sera prête pour la production ; l'avertissement étant que rien n'est plus important que la fiabilité des données. Ainsi, contrairement à tout autre aspect d'un système, une approche conservatrice à l'égard du déploiement initial et des tests est obligatoire.

Tout en gardant cela à l'esprit, nous implémenterons ReFS dans une évolution par étapes de la fonctionnalité : d'abord en tant que système de stockage pour Windows Server, ensuite en tant que stockage pour les clients, puis enfin en tant que volume de démarrage. C'est l'approche que nous avons utilisée avec les nouveaux systèmes de fichiers par le passé.

À l'origine, notre premier test visera à exécuter ReFS en tant que serveur de fichiers. Nous pensons que les clients tireront pleinement parti de l'utilisation de ReFS en tant que serveur de fichiers, en particulier sur une version répliquée en miroir de Storage Space. Nous prévoyons également de collaborer avec nos partenaires de stockage pour l'intégrer à leurs solutions de stockage.

Conclusion

Avec Storage Spaces, ReFS forme la base du stockage sous Windows de la prochaine décennie ou plus. Nous pensons que cela constitue une avancée considérable en matière de stockage. Ensemble, Storage Spaces et ReFS ont été conçus pour pousser l'innovation encore plus loin et que espérons que ReFS deviendra le prochain système de fichiers déployé massivement.

-- Surendra

FAQ :

Q) Pourquoi ce système s'appelle-t-il ReFS ?

ReFS est l'abréviation de Resilient File System (système de fichiers fiable). Bien qu'il soit conçu pour être meilleur dans bien des aspects, la fiabilité s'impose comme l'une des fonctionnalités prédominantes.

Q) Quelles sont les limites en termes de capacité de ReFS ?

La table ci-dessous montre les limites en termes de capacité du format du disque. D'autres aspects peuvent déterminer certaines limites pratiques, telles que la configuration du système (par exemple, la quantité de mémoire), les limites définies par différents composants système, ainsi que la durée nécessaire pour renseigner les jeux de données, les durées des sauvegardes, etc.

Q) Puis-je convertir des données entre NTFS et ReFS ?

Sous Windows 8, il n'est pas possible de convertir les données en place. Les données peuvent être copiées. Cette décision de conception a été prise de façon intentionnelle, étant donné la taille des jeux de données que nous voyons actuellement et le côté peu pratique de cette conversion sur place, outre le changement probable de l'approche architecturée avant et après la conversion.

Q) Puis-je démarrer à partir de ReFS sous Windows Server 8 ?

Non, cela n'est pas implémenté ou pris en charge.

Q) ReFS peut-il être utilisé sur des supports ou des lecteurs amovibles ?

Non, cela n'est pas implémenté ou pris en charge.

Q) Quelles sont les fonctionnalités ou la sémantique de NTFS qui ne sont plus prises en charge dans ReFS ?

Les fonctionnalités NTFS que nous avons choisies de ne plus prendre en charge dans ReFS sont les suivantes : flux nommés, ID objet, noms courts, compression, chiffrement au niveau des fichiers (EFS), transactions des données utilisateur, allocation partielle, liens directs, attributs étendus et quotas.

Q) Qu'en est-il des espaces de parité et de ReFS ?

ReFS est pris en charge sur les options de tolérance aux pannes fournies par Storage Spaces. Sous Windows Server 8, la correction automatique des données est implémentée uniquement pour les espaces répliqués en miroir.

Q) Est-ce que le clustering est pris en charge ?

Le clustering de basculement est pris en charge, où les volumes individuels peuvent basculer sur plusieurs machines. En outre, les pools de stockage partagés dans un cluster sont pris en charge.

Q) Qu'en est-il de RAID ? Comme utiliser les fonctionnalités ReFS d'agrégation par bandes, de réplication en miroir ou d'autres formes de RAID ? Est-que ReFS fournit les performances de lecture nécessaires pour la vidéo, par exemple ?

ReFS utilise les fonctionnalités de Storage Spaces en matière de redondance des données, ce qui inclut l'agrégation par bandes, la réplication en miroir et la parité. Les performances de lecture de ReFS sont censées être similaires à celles de NTFS, avec lequel il partage une grande partie du code approprié. Il sera parfait pour diffuser les données en continu.

Q) Pourquoi est-ce que ReFS ne comporte pas de déduplication, de mise en cache de deuxième niveau entre DRAM et le stockage et de captures instantanées inscriptibles ?

ReFS n'offre pas de déduplication lui-même. Une des conséquences de son architecture de système de fichiers familière et enfichable est que d'autres produits de déduplication seront capables de s'intégrer à ReFS comme ils le font avec NTFS.

ReFS n'implémente pas de façon explicite un cache de deuxième niveau, mais les clients peuvent utiliser des solutions tierces pour cela.

ReFS et VSS fonctionnent ensemble pour fournir des captures instantanées de façon cohérente avec NTFS dans les environnements Windows. Pour le moment, ils ne prennent pas en charge les captures instantanées inscriptibles ou les captures instantanées dont la taille dépasse 64 To.