elgaid59
عضو ذهبي
عدد المساهمات : 9637
نقاط : 37078
تاريخ التسجيل : 21/08/2007
 | | موضوع: وداعا NTFS.SYS و اهلا بالقادم الجديد ReFS.SYS 24/4/2012, 11:42 | |
| ......  بدون مقدمات
من مميزاته مساحة تخزين أكبر
و وصول للبيانات بشكل أسرع
لمزيد من التفاصيل الكاملة عن هذا النظام الجديد
من موقع مايكروسوفت هنـــا باللغة الأنجليزية
او من هنا باللغة العربية .............
Création du système de fichiers de prochaine génération pour Windows : ReFS
 Steven Sinofsky
Steven Sinofsky
Microsoft Corporation
125,367 Points 4 3 4
Recent Achievements
Blogs All-Star Blog Commentator III New Blog Rater
View Profile
samedi 21 janvier 2012 01:47
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
D:\>format /fs:refs /q /i:disable
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.
| |
|
الرئيسية
