État du cache dans la racine de virtualisation

  • Article

Le fournisseur utilise le système de fichiers local sous la racine de virtualisation comme cache des éléments qu’il gère. Un élément (fichier ou répertoire) peut se trouver dans l’un des six états du système de fichiers local :

  • Les machines

    L’élément n’existe pas localement sur le disque. Il est projeté, c’est-à-dire synthétisé, lors des énumérations de son répertoire parent. Les éléments virtuels sont fusionnés avec tous les éléments qui peuvent exister sur le disque pour présenter le contenu complet du répertoire parent.

  • Espace réservé

    Pour les fichiers : le contenu du fichier (flux de données principal) n’est pas présent sur le disque. Les métadonnées du fichier (nom, taille, horodatages, attributs, etc.) sont mises en cache sur le disque.

    Pour les répertoires : une partie ou la totalité des descendants immédiats du répertoire (les fichiers et répertoires du répertoire) ne sont pas présents sur le disque, c’est-à-dire qu’ils sont toujours virtuels. Les métadonnées du répertoire (nom, horodatages, attributs, etc.) sont mises en cache sur le disque.

  • Espace réservé hydraté

    Pour les fichiers : le contenu et les métadonnées du fichier ont été mis en cache sur le disque. Également appelé « fichier partiel ».

    Pour les répertoires : un répertoire créé sur le disque en tant qu’espace réservé ne devient jamais un répertoire d’espace réservé hydraté. Cela permet au fournisseur d’ajouter ou de supprimer des éléments du répertoire dans son magasin de stockage et d’afficher ces modifications dans le cache local.

  • Espace réservé sale (hydraté ou non)

    Les métadonnées de l’élément ont été modifiées localement et ne sont plus un cache de son état dans le magasin du fournisseur. Notez que la création ou la suppression d’un fichier ou d’un répertoire sous un répertoire d’espace réservé entraîne la sale de ce répertoire.

  • Fichier/répertoire complet

    Pour les fichiers : le contenu du fichier (flux de données principal) a été modifié. Le fichier n’est plus un cache de son état dans le magasin du fournisseur. Les fichiers qui ont été créés sur le système de fichiers local (c’est-à-dire qui n’existent pas du tout dans le magasin du fournisseur) sont également considérés comme des fichiers complets.

    Pour les répertoires : les répertoires créés sur le système de fichiers local (c’est-à-dire qui n’existent pas du tout dans le magasin du fournisseur) sont considérés comme des répertoires complets. Un répertoire créé sur le disque en tant qu’espace réservé ne devient jamais un répertoire complet.

  • Pierre tombale

    Espace réservé masqué spécial qui représente un élément qui a été supprimé du système de fichiers local. Lorsqu’un répertoire est énuméré, ProjFS fusionne l’ensemble des éléments locaux (espaces réservés, fichiers complets, etc.) avec l’ensemble d’éléments projetés virtuels. Si un élément apparaît dans les jeux locaux et projetés, l’élément local est prioritaire. Si un fichier n’existe pas dans le système de fichiers local, il n’y a pas d’état local. Il apparaît donc dans l’énumération. Toutefois, si cet élément avait été supprimé, son affichage dans l’énumération serait inattendu. Le remplacement d’un élément supprimé par une pierre tombstone entraîne les effets suivants :

    • Énumérations pour ne pas révéler l’élément.
    • Le fichier s’ouvre qui s’attend à ce que l’élément existe échoue avec, par exemple, « fichier introuvable ».
    • Les créations de fichiers qui s’attendent à réussir uniquement si l’élément n’existe pas réussissent ; ProjFS supprime la pierre tombstone dans le cadre de l’opération.

Pour illustrer les états ci-dessus, considérez la séquence suivante, étant donné qu’un fournisseur ProjFS a un seul fichier « foo.txt » situé dans la racine de virtualisation C:\root.

  1. Une application énumère C:\root. Il voit le fichier virtuel « foo.txt ». Étant donné que le fichier n’a pas encore été consulté, il n’existe pas sur le disque.
  2. L’application ouvre un handle pour C:\root\foo.txt. ProjFS indique au fournisseur de créer un espace réservé pour celui-ci.
  3. L’application lit le contenu du fichier. Le fournisseur fournit le contenu du fichier à ProjFS et il est mis en cache pour C:\root\foo.txt. Le fichier est maintenant un espace réservé hydraté.
  4. L’application met à jour l’horodatage de la dernière modification. Le fichier est maintenant un espace réservé sale hydraté.
  5. L’application ouvre un handle pour l’accès en écriture au fichier. C:\root\foo.txt est maintenant un fichier complet.
  6. L’application supprime C:\root\foo.txt. ProjFS remplace le fichier par une pierre tombstone. À présent, lorsque l’application énumère C:\root, elle ne voit pas foo.txt. S’il tente d’ouvrir le fichier, l’ouverture échoue avec ERROR_FILE_NOT_FOUND.